Как выбрать сервер под виртуализацию и 1С
Сервер под виртуализацию и 1С — это две во многом противоположные нагрузки в одном корпусе, и ошибка в балансе ресурсов обходится дороже самой железки. Виртуализация любит много ядер, много памяти и высокую плотность, чтобы упаковать десятки виртуальных машин на один хост и поднять утилизацию оборудования: в виртуальной среде сегодня работает около 95% серверов именно по экономическим причинам. 1С устроена иначе — её платформа в части сеанса пользователя по сути однопоточная: каждый запрос, проведение документа и формирование отчёта обрабатывается одним потоком сервера приложений, поэтому система упирается в частоту отдельного ядра и в задержки дисковой подсистемы, а не в суммарное число ядер. Прежде чем выбирать платформу, зафиксируйте профиль нагрузки: сколько виртуальных машин и с каким резервом, сколько одновременных активных пользователей 1С, какой режим — файловый или клиент-серверный на PostgreSQL/Postgres Pro или MS SQL, разнесены ли роли сервера приложений и сервера базы данных.
Форм-фактор определяется тем, где сервер будет жить и как масштабироваться. Стоечный 1U — максимальная плотность на юнит, но ограниченные дисковые корзины, более шумное и горячее охлаждение и меньше места под карты расширения; 2U — фактический стандарт под универсальную нагрузку: запас под диски (включая NVMe-бэкплейн), полноразмерные блоки питания с резервированием, тише и холоднее. Башенный (tower) уместен в офисе без стойки и для небольших филиалов. Blade и мультинодовые шасси оправданы при массовой однотипной виртуализации в ЦОД, где важнее плотность стойки и общее питание/охлаждение, чем гибкость отдельного узла. Главное правило: если планируете рост, берите двухсокетную платформу со свободными слотами памяти и дисковыми отсеками заранее — апгрейд процессора и памяти кратно дешевле покупки второго сервера и новой лицензии гипервизора.
По процессорам действуют два разных критерия для двух задач. Для виртуализации считайте суммарное число физических ядер с запасом 20–30% сверх пиковой потребности всех виртуальных машин, учитывайте число каналов памяти и линий PCIe под диски и сеть. Для 1С на первый план выходит базовая и turbo-частота ядра и объём кэша: фирма «1С» де-факто рекомендует частоту от 3 ГГц, и сервер с 32 медленными ядрами проиграет в проведении документов серверу с 16 ядрами на 3,5+ ГГц. Современные платформы закрывают обе задачи — Intel Xeon Scalable 4–5 поколений (Sapphire Rapids, Emerald Rapids на сокете LGA4677) и Xeon 6, а также AMD EPYC Genoa/Turin (сокет SP5, до 12 каналов DDR5 и большое число ядер на сокет). Переход с Sapphire Rapids на Emerald Rapids в типовых серверных нагрузках даёт порядка 20% прироста на том же сокете после обновления BIOS — недорогой апгрейд без замены стойки.
AMD против Intel — это вопрос профиля, а не лозунга «кто быстрее в бенчмарке». Показательный кейс 2025–2026: на синтетическом тесте Гилёва Intel Xeon Gold 6548Y набрал 60 баллов, а AMD EPYC 9274F — 58, то есть формально проиграл. Но на реальном закрытии месяца в базе 1С:ERP тот же EPYC оказался примерно на треть быстрее. Вывод простой: синтетика и прикладной сценарий могут расходиться, поэтому решающий аргумент — тест на вашей базе и вашем профиле операций, а не абсолютные цифры из чужого отчёта. Для лицензий, которые считаются «по ядрам» (часть СУБД, ряд гипервизоров), цена за ядро у EPYC с высокой частотой часто привлекательнее; для ISV-сертифицированного enterprise-софта традиционно богаче экосистема Intel. И ту, и другую платформу под 1С имеет смысл подбирать в моделях с высокой turbo-частотой, чтобы выигрывать на пиковых однопоточных операциях в начале дня и при закрытии периода.
Память — почти всегда первый дефицит при виртуализации и критичный ресурс для СУБД 1С. ECC-модули обязательны: гипервизор и база данных не прощают одиночных битовых ошибок, а ECC их обнаруживает и исправляет «на лету». Заполняйте каналы памяти симметрично (по числу каналов контроллера — у современных EPYC их до 12, у Xeon — 8), иначе теряете значимую часть пропускной способности. Практический ориентир: закладывайте 8–16 ГБ на типовую виртуальную машину плюс память под сам гипервизор и кэш ОС; для клиент-серверной 1С отдельно считайте память сервера баз данных — чем большая доля рабочей базы помещается в кэш СУБД, тем меньше обращений к диску и тем быстрее отклик. По числу пользователей разумные точки отсчёта: 16–32 ГБ на 10–20 человек, 64–128 ГБ на 30–50, от 128–256 ГБ на 100+ при разнесённых ролях.
Дисковая подсистема — то, на чём чаще всего экономят и потом страдают. Под 1С, журналы транзакций и СУБД нужны NVMe или, как минимум, корпоративные SAS SSD: задержка операций ввода-вывода напрямую превращается в «тормоза» у пользователей при проведении документов и закрытии периода, а IOPS важнее «терабайтов». Не путайте слои при заказе: тип накопителя (HDD/SSD/флеш), протокол (SATA/SAS/NVMe), форм-фактор (2.5/3.5, M.2, U.2/U.3, EDSFF) и поддержку конкретной серверной платформой (бэкплейн, число PCIe-линий, охлаждение) — «M.2» вполне может оказаться медленным SATA, а под NVMe в шасси может просто не быть корзины. SATA HDD оставьте под бэкапы и холодные архивы. Массив под продуктивную базу собирайте с избыточностью и аппаратным контроллером с защищённым кэшем (BBU/CacheVault) — иначе при сбое питания режим write-back способен «потерять» подтверждённые записи и повредить целостность базы.
Сеть и резервирование часто недооценивают. Для разнесённой архитектуры App/DB и для терминальных сценариев (RDS/VDI) пропускная способность и задержка сети между узлами влияют на отклик не меньше дисков — минимум 10GbE для трафика СУБД и хранилища, отдельный сегмент под управление (BMC/iLO/iDRAC) и резервное копирование, VLAN-сегментация под требования ИБ. Резервируйте критичные компоненты: два блока питания на разные линии, RAID под систему и базу, горячая замена дисков и вентиляторов. Для отказоустойчивости продуктивной 1С на уровне приложения помогает кластер серверов 1С, а на уровне СУБД — встроенные механизмы вроде BiHA в Postgres Pro Enterprise; это снижает простои, но не заменяет бэкап.
Гипервизор — отдельная стратегическая развилка, и в российских реалиях она изменилась радикально. После того как VMware (Broadcom) ушла с рынка, отключила аккаунты и прекратила поддержку и продажу лицензий, а с 1 января 2025 года значимые объекты КИИ обязали использовать только отечественное ПО, переход на российские системы виртуализации превратился из опции в необходимость. По отраслевым оценкам уже около 78% организаций выбирают отечественные платформы. Технически почти все они построены вокруг открытого ядра KVM/QEMU (часть — на наследии oVirt/Xen), поэтому работают на стандартной серверной элементной базе и совместимы с российскими дистрибутивами Linux и сертифицированными ОС.
Конкретные кандидаты на 2025–2026: zVirt (Orion soft) — один из лидеров по числу инсталляций и зрелости, ориентир на миграцию с VMware; ROSA Virtualization и «Альт Виртуализация» — решения с собственными экосистемами ОС; «Брест» (РусБИТех-Астра) — для контуров на Astra Linux с акцентом на защищённость и сертификацию; из открытых — Proxmox VE и «голый» KVM для бюджетных и технически зрелых команд. Растёт и гиперконвергенция (HCI), где вычисления и хранилище объединены в одном программном слое. Выбор делайте по матрице совместимости с вашей ОС и оборудованием, наличию техподдержки и сертификатов ФСТЭК, а также по тому, насколько гладко конвертируются ваши существующие виртуальные машины — миграция с VMware остаётся самой трудоёмкой частью проекта.
Лицензирование считайте заранее и целиком — это часть TCO, а не сноска. У гипервизоров модель обычно «по сокетам» или «по ядрам/хостам» плюс подписка на поддержку; у СУБД под 1С важно, что в реестре российского ПО сертифицированы Postgres Pro (включая редакции «для 1С» и Enterprise) и Tantor — это снимает зависимость от MS SQL и закрывает требования импортозамещения. Сама 1С лицензируется отдельно: клиентские лицензии по числу пользователей плюс лицензия на сервер 1С (для серьёзных нагрузок — версия КОРП). На стороне ОС — сертифицированные Astra Linux, РЕД ОС, РОСА и аналоги. Сумма всех подписок и лицензий нередко сопоставима со стоимостью железа, поэтому конфигурацию «железо + гипервизор + ОС + СУБД + 1С» надо проектировать как единый комплект.
Сведём в типовые ориентиры по числу одновременных активных пользователей 1С (это именно ориентиры — точная конфигурация требует аудита и нагрузочного теста, потому что один и тот же сервер может комфортно держать 20 пользователей в одной компании и «лечь» на 10 в другой). До 10–15 пользователей: 1 сокет, 6–8 ядер от 3,2 ГГц, 32–64 ГБ ECC, пара NVMe в зеркале под базу. 30–50 пользователей: 1–2 сокета, 12–16 быстрых ядер, 128 ГБ ECC, разнесение ролей App и DB, NVMe-массив под СУБД и журналы. 100+ пользователей: двухсокетная платформа, 16+ ядер с высокой turbo-частотой на узел, 256 ГБ и выше, отдельный сервер баз данных с многоядерным CPU под параллелизм SQL, кластеризация и быстрый отказоустойчивый сторедж. Под виртуализацию поверх этого добавляйте суммарные ядра и память всех ВМ с запасом 20–30% и закладывайте ресурсы под сам гипервизор.
Итог: начните с профиля нагрузки, затем разведите два критерия — высокую частоту ядра под однопоточную 1С и достаточное число ядер и памяти под плотную виртуализацию, не экономьте на ECC-памяти, быстрых NVMe и аппаратном контроллере с защищённым кэшем, заложите запас под рост и аппаратное резервирование, а гипервизор и СУБД выбирайте сразу под требования импортозамещения и реестры. Проверяйте кандидатов не по синтетике, а тестом на вашей базе. Если нужно собрать сбалансированную конфигурацию под конкретный бюджет, число пользователей и контур (включая КИИ и сертифицированный стек) — пришлите нам список задач, инженеры RackCore подготовят спецификацию и подберут проверенные аналоги, если нужной модели нет в наличии.