При выборе серверного процессора легко сосредоточиться на частоте, количестве ядер, кешах и теплопакете. Но в корпоративной инфраструктуре это часто только половина картины. Вторая половина — лицензии. Для Windows Server, SQL Server, части продуктов VMware/Broadcom и ряда решений Oracle именно модель лицензирования может сильнее влиять на итоговую экономику, чем разница в цене между двумя CPU. У Microsoft для Windows Server при лицензировании по физическим ядрам нужно лицензировать все physical cores, при этом действует минимум 8 ядер на процессор и 16 ядер на сервер. У Oracle для Processor metric количество лицензий зависит не только от числа ядер, но и от коэффициента в Core Factor Table. У актуальных per-core моделей Broadcom/VMware также используется минимальный объём лицензирования на процессор.
Из этого следует простой вывод: “самый мощный” процессор не всегда самый выгодный. Если два сервера стоят близко, но один имеет 16 быстрых ядер, а другой 32 более медленных, второй может оказаться заметно дороже по лицензиям при сопоставимой прикладной производительности. Поэтому CPU под лицензируемое ПО выбирают не по числу ядер само по себе, а по тому, сколько полезной производительности даёт каждое лицензируемое ядро.
Почему CPU нельзя выбирать отдельно от модели лицензирования
Для open source-сервисов или части SaaS-нагрузок число ядер может не быть критичным с точки зрения лицензий. Но в enterprise-сегменте лицензируется не “сервер в целом”, а конкретная сущность: физические ядра, сокеты, vCPU или процессорный эквивалент по правилам вендора.
Здесь важно не путать термины:
- physical core — физическое ядро CPU;
- thread — логический поток SMT/Hyper-Threading;
- socket — физический процессорный разъём;
- vCPU — виртуальный процессор в гипервизоре или облаке;
- licensed core — ядро, которое попадает под правила лицензирования;
- processor metric — лицензируемая единица, рассчитываемая по формуле вендора.
Это не одно и то же. Потоков обычно больше, чем физических ядер, но лицензирование чаще привязано именно к physical cores. Ещё одна ловушка — минимальные пороги. Если у вендора есть правило “не менее N ядер на процессор”, то низкоядерная конфигурация не всегда даёт ожидаемую экономию.
Перед выбором CPU нужно ответить на шесть вопросов:
- Как именно лицензируется нужный продукт?
- Считаются physical cores, sockets, vCPU или processor metric?
- Есть ли minimum per server или minimum per processor?
- Есть ли коэффициенты по архитектуре CPU?
- Лицензируется весь хост или только выделенные ВМ/ядра?
- Есть ли дополнительные требования вроде CAL, подписки или Software Assurance?
Без этих ответов выбор процессора превращается в угадывание.
Какие модели лицензирования встречаются чаще всего
На практике полезно держать в голове не десятки частных схем, а четыре базовые модели.
Лицензирование по физическим ядрам
Это один из самых важных сценариев для серверной инфраструктуры. У Windows Server лицензируются все физические ядра сервера, при этом действует минимум 8 ядер на процессор и 16 ядер на сервер. У SQL Server для соответствующих редакций и сценариев также используется core-based модель. Это означает, что каждое дополнительное ядро может напрямую увеличивать лицензионную стоимость.
Лицензирование по CPU или по CPU с ограничением по ядрам
Исторически такая модель была распространена шире. В современной практике она нередко трансформирована: лицензия может быть привязана к CPU, но покрывать его только до определённого числа ядер, либо использовать minimum core entitlement на процессор. Для актуальных продуктов Broadcom/VMware по per-core модели минимальная покупаемая ёмкость составляет 16 ядер на CPU. Это сразу меняет математику для low-core и high-core конфигураций.
Лицензирование по коэффициенту процессора
Это характерно для части продуктов Oracle. В такой схеме число требуемых лицензий зависит не только от количества ядер, но и от коэффициента для конкретного типа процессора. Один и тот же 32-core CPU в разных архитектурных семействах может приводить к разному числу лицензий. Поэтому смотреть только на core count здесь опасно: нужно сверяться с Core Factor Table и правилами конкретного продукта.
Лицензирование по vCPU и облачным инстансам
В облаке и виртуализации правила могут отличаться от bare metal. Например, Oracle прямо указывает, что в Authorized Cloud Environments Core Factor Table не применяется так же, как на физическом оборудовании. Это важный момент: нельзя автоматически переносить on-prem правила на облако или наоборот.
Главный принцип: максимум производительности на лицензируемое ядро
Когда лицензии считаются по ядрам, важен не просто суммарный throughput сервера. Важнее метрика полезная производительность на одно лицензируемое ядро.
Почему это так:
- каждое дополнительное ядро может стоить денег не только в железе, но и в лицензиях;
- многие корпоративные приложения масштабируются не линейно;
- для OLTP, ERP, CRM и части middleware выше значение latency и производительности одного ядра, чем предельного числа параллельных потоков;
- высокий core density полезен не всегда: иногда он лишь раздувает стоимость лицензий.
Из этого вытекает практическое правило. При core-based licensing часто выгоднее CPU с меньшим числом более сильных ядер, если нагрузка чувствительна к однопоточной производительности и не масштабируется идеально.
Это особенно верно, когда:
- лицензия считается по physical cores;
- приложение плохо масштабируется по ядрам;
- важны отклик и производительность отдельного потока;
- сервер покупается под одну конкретную лицензируемую систему;
- число инстансов заранее ограничено.
Больше ядер оправданы в других условиях:
- лицензия не зависит от числа ядер;
- workload хорошо распараллеливается;
- сервер планируется под консолидацию нескольких сервисов;
- используется модель лицензирования по vCPU, подписке или иным правилам;
- задача упирается в параллелизм, а не в скорость одного ядра.
Как сравнивать CPU в лицензируемых сценариях
Практический выбор лучше делать не по маркетинговым спецификациям, а по алгоритму.
Шаг 1. Определите лицензируемую сущность
Нужно точно понять, что считается: физические ядра, сокеты, vCPU, процессорный эквивалент или минимальный порог на CPU/сервер. Этот шаг нельзя пропускать. Обязателен к ознакомлению licensing guide от вендора, в неоднозначных сценариях лучше проконсультироваться со специалистом также от вендора. Советы в интернете и у поставщиков могут быть некорректны, в том числе в связи с периодическими сменами модели лицензирования (например не так давно VMware лицензировалась по сокетам).
Шаг 2. Зафиксируйте тип нагрузки
Одно дело — транзакционная БД, другое — виртуализация смешанных сервисов, третье — аналитика. Один и тот же CPU может быть выгоден в одном сценарии и невыгоден в другом.
Шаг 3. Оцените требуемую производительность для конкретной задачи
Смотрите не на “мощнее вообще”, а на:
- latency;
- throughput;
- пиковую нагрузку;
- требования по росту на 2–3 года;
- HA/DR-сценарии.
Шаг 4. Считайте лицензии поверх стоимости железа
Корректная формула выглядит так:
Итоговая стоимость владения = стоимость сервера + стоимость лицензий + поддержка/подписка + запас на рост
Именно на этом этапе часто выясняется, что более дешёвый с виду CPU делает проект дороже, или небольшая переплата "за ядра" меняет стоимость владения кардинально.
Шаг 5. Сравнивайте кандидатов по метрике “полезная производительность / лицензируемое ядро”
Это самая практичная метрика для таких задач. Не “сколько ядер”, а “сколько результата получаем с каждого оплачиваемого ядра”.
Как модель лицензирования влияет на выбор CPU
| Модель | Что считается | Что это значит для выбора CPU | Обычно выгоднее |
|---|---|---|---|
| Core-based | Физические ядра | Каждое лишнее ядро может увеличить стоимость лицензий | Меньше, но сильнее ядра при чувствительной к latency нагрузке |
| Per-CPU с ограничением или minimum\maximum cores | CPU и минимальный core entitlement | Low-core CPU не всегда даёт пропорциональную экономию | Считать не только сокеты, но и minimum\maximum per CPU |
| Processor metric с factor | Ядра × коэффициент | Важна не только плотность ядер, но и архитектура CPU | Проверять factor до выбора платформы |
| vCPU / cloud-oriented | Виртуальные CPU или инстансы | On-prem логика не всегда переносится в облако или даже виртуальные машины | Сравнивать уже на уровне облачной математики |
Где чаще всего переплачивают
Путают ядра и потоки
SMT и Hyper-Threading повышают плотность вычислений, но не обязательно превращают сервер в “вдвое больше лицензируемый”. Потоки и физические ядра — разные сущности.
Игнорируют minimum licensing rules
Если у Windows Server минимум 8 ядер на процессор и 16 на сервер, то 6-core или 10-core конфигурация не обязательно даст ту экономию, которую ожидают по простой арифметике. Это один из самых типичных просчётов.
Берут CPU “с запасом”, который не нужен
Дополнительные ядра нередко покупаются “на будущее”, но при core-based licensing этот запас оплачивается сразу и железом, и лицензиями. Если план роста не подтверждён, такой запас может оказаться дорогой ошибкой.
Переносят on-prem правила в облако без проверки
У Oracle для облачных сценариев действуют отдельные правила, и Core Factor Table в Authorized Cloud Environments не применяется так же, как на физическом сервере.
Смотрят только на бенчмарки
Synthetic benchmark помогает понять класс CPU, но не отвечает на главный вопрос: сколько полезной прикладной производительности вы получите на одно лицензируемое ядро.
Один сокет или два
Выбор между 1P и 2P не сводится к “два сокета лучше”. При лицензировании по ядрам он зависит от баланса между лицензиями и архитектурными потребностями.
Один сокет часто выгоднее, если:
- нагрузка умеренная;
- хватает памяти и PCIe-ресурсов одной платформы;
- нет задачи консолидации;
- важно минимизировать число лицензируемых ядер и NUMA-сложность.
Два сокета могут быть оправданы, если:
- нужен большой объём памяти;
- требуется больше PCIe-линий;
- планируется консолидация нескольких сервисов;
- есть реальный запас по росту, который будет использован.
Но если ПО лицензируется по всем физическим ядрам сервера, второй сокет без практической необходимости может резко ухудшить экономику проекта.
Практические сценарии
SQL Server и транзакционные БД
Для SQL Server core-based licensing делает особенно важной производительность на ядро. В транзакционных системах часто выгоднее меньшее число более быстрых ядер, чем максимальная плотность ядер. Это помогает получить нужную производительность без лишнего роста лицензионной стоимости.
Windows Server для инфраструктурных ролей
Если сервер выполняет роли AD, файлового сервера, DNS, DHCP или похожие задачи, high-frequency CPU нужен не всегда. Важно не купить больше ядер, чем реально требуется, особенно с учётом minimum 8/16. Здесь экономически разумная конфигурация часто лучше “топового” процессора.
Oracle-нагрузка
В Oracle нельзя смотреть только на core count. Processor metric и Core Factor Table означают, что архитектура CPU влияет на число лицензий. Иногда различие в licensing math оказывается важнее, чем разница в цене сервера или даже умеренная разница в производительности.
Виртуализация и VMware-пул
Для актуальных per-core моделей Broadcom/VMware высокая плотность ядер не бесплатна. Нужно считать лицензирование всего пула ESXi-хостов и помнить о минимуме 16 ядер на CPU. Здесь процессор выбирают не отдельно, а в связке с общей моделью лицензирования виртуализационного стека.
Чек-лист выбора CPU под лицензируемое ПО
| Вопрос | Почему важен | Что проверить |
|---|---|---|
| Какой тип лицензии у продукта | От этого зависит вся математика | Core, socket, vCPU, factor, subscription |
| Есть ли minimum per processor/server | Ломает “наивную” экономию | Правила 8/16, 16 per CPU и аналоги |
| Что именно считается | Не путать core, thread и vCPU | Product terms и licensing guide |
| Есть ли коэффициент по архитектуре | Меняет число лицензий | Core Factor Table или эквивалент |
| Как масштабируется приложение | Больше ядер не всегда полезнее | OLTP, аналитика, виртуализация |
| Нужен ли реальный запас на рост | Лишние ядра стоят денег | План роста на 2–3 года |
| Сравниваем ли performance per licensed core | Это главный показатель | Тесты и sizing под конкретную задачу |
Вывод
При лицензировании по ядрам оптимальный CPU — не тот, у которого просто больше ядер, а тот, который даёт нужной нагрузке максимум полезной производительности при минимальной стоимости лицензируемого вычислительного ресурса.
Правильная последовательность всегда одна и та же: сначала выясняется модель лицензирования, затем профиль нагрузки, потом считаются ограничения по масштабированию, и только после этого выбирается процессор. Во многих сценариях лучшая метрика — производительность на лицензируемое ядро плюс общая стоимость владения.
И последнее: даже если общая логика понятна, перед закупкой нужно обязательно сверяться с актуальными licensing terms конкретного продукта, редакции и канала поставки. В этой теме важны детали, а они у вендоров меняются чаще, чем кажется.
