Лицензирование SQL Server по ядрам и CAL

Как считать лицензии SQL Server по ядрам и CAL — полный разбор

SQL Server лицензируется по двум моделям — Core-based (по физическим ядрам процессора) и Server + CAL (серверная лицензия плюс клиентские лицензии на каждого пользователя или устройство). Выбор зависит от редакции, числа пользователей и типа доступа к базе данных, и неправильный выбор может стоить сотни тысяч рублей переплаты.

Две модели лицензирования SQL Server — зачем вообще два варианта

Давайте по порядку. Microsoft не стала делать единую схему, потому что сценарии использования SQL Server слишком разные. Одно дело — бухгалтерия на 10 человек, которая работает с 1С через SQL Server. Совсем другое — интернет-магазин с десятками тысяч посетителей в сутки.

Модель Server + CAL устроена так: вы покупаете одну серверную лицензию SQL Server и к ней отдельные лицензии на каждого пользователя (User CAL) или на каждое устройство (Device CAL), которое обращается к базе. Просто? На первый взгляд да.

Модель Core-based работает иначе. Вы платите за количество физических ядер в процессоре (или процессорах) сервера. Никакие CAL не нужны. Подключайте хоть миллион пользователей.

Вот в чём прикол — Enterprise доступен только по ядрам. Server + CAL можно использовать только со Standard. Это сразу отсекает половину вопросов: если вам нужен Enterprise, считайте ядра и не думайте про CAL.

А зачем вообще кому-то Enterprise? Ну, если честно, для большинства задач Standard хватает за глаза. Enterprise нужен для Always On Availability Groups с несколькими базами, In-Memory OLTP без ограничений, компрессии данных и работы с серверами, у которых больше 24 ядер для вычислений или больше 128 ГБ RAM.

Как считать ядра — правила, которые многие путают

Тут такое дело. Правила подсчёта ядер для SQL Server отличаются от того, что вы привыкли видеть в диспетчере задач. Считаются физические ядра, не логические процессоры. Hyper-Threading создаёт виртуальные потоки, но для лицензирования они не учитываются.

Основные правила:

1. Минимум 4 ядра на каждый физический процессор
2. Лицензии продаются пакетами по 2 ядра (2-Core Pack)
3. Минимум на весь сервер — тоже 4 ядра (2 пакета)
4. Лицензируются все физические ядра на сервере, нельзя лицензировать только часть

У Серёги (Dell PowerEdge R740, 2x Xeon Gold 6248, 40 ядер суммарно, 128 ГБ RAM) была такая ситуация — он купил SQL Server Standard и начал считать. 40 ядер, значит 20 пакетов 2-Core Pack. Но тут он вспомнил, что Standard ограничен 24 ядрами для вычислений. Возникает вопрос: лицензировать 24 или все 40?

Короче, ответ такой. Если SQL Server работает на физическом сервере, вы обязаны лицензировать все физические ядра. Даже если Standard использует только 24 из 40. Это правило Microsoft, и оно не обсуждается. Можно, правда, ограничить SQL Server через affinity mask и виртуализацию, но на физике — все ядра.

А вот на виртуалке всё проще. Лицензируете только те vCPU, которые назначены виртуальной машине. Минимум — 4 vCPU. Поэтому многие специально ставят SQL Server Standard на ВМ с 24 vCPU (или меньше) и лицензируют только их, а не все 40 ядер хоста.

-- Проверить количество ядер из самого SQL Server
-- это для тех кто копирует не глядя
SELECT cpu_count AS logical_processors,
       cpu_count / hyperthread_ratio AS physical_cores,
       hyperthread_ratio
FROM sys.dm_os_sys_info;

-- Если hyperthread_ratio = 2, значит HT включен
-- physical_cores - вот это число вам нужно для лицензирования

Модель Server + CAL — подробный разбор

Эта модель выглядит привлекательно для небольших команд. Одна серверная лицензия плюс по одной CAL на каждого пользователя или устройство. Всё.

Но есть нюансы (и их немало).

User CAL привязывается к конкретному человеку. Этот человек может подключаться к SQL Server с любого количества устройств — с рабочего компа, с ноутбука, с телефона. Одна лицензия покрывает все его устройства.

Device CAL привязывается к устройству. С этого устройства к SQL Server может подключаться любое количество пользователей. Хороший вариант для терминальных станций (вот где экономия!) и устройств, за которыми работают посменно.

Кстати, можно смешивать User CAL и Device CAL в рамках одного сервера. Microsoft это разрешает. Но на практике это создаёт головную боль при учёте, и мало кто так делает.

Знаете что? Самая частая ошибка — люди считают CAL по числу одновременных подключений. Нет, подождите… SQL Server это не конкурентная модель. Не «сколько человек одновременно подключено», а «сколько человек имеет право подключаться». Даже если Маша подключается раз в месяц — ей нужна CAL.

Когда CAL не работает — история про мультиплексинг

По факту, это самый коварный момент в лицензировании SQL Server. Мультиплексинг — это когда между пользователями и SQL Server стоит промежуточное ПО. Веб-сервер, middleware, пул соединений, что угодно.

Допустим, ваш веб-сервер подключается к SQL Server через 5 connection pool соединений. А через веб-приложение работают 300 пользователей. Сколько CAL нужно? Не 5. Нужно 300.

Microsoft чётко прописывает: мультиплексинг не уменьшает количество необходимых CAL. Считаются конечные пользователи, а не соединения.

У Димы (Lenovo ThinkStation P620, Ryzen Threadripper PRO 3955WX, 64 ГБ RAM) на работе развернули внутренний портал на ASP.NET, который хранил данные в SQL Server. Пул соединений держал 10 подключений. Дима решил, что хватит 10 CAL. А потом при подготовке к аудиту (да, Microsoft реально проводит аудиты) выяснилось, что порталом пользуются 120 сотрудников. Пришлось либо докупать 110 CAL, либо переходить на модель по ядрам.

Грубо говоря, если у вас есть веб-приложение, через которое к SQL Server обращается неопределённое число пользователей — забудьте про CAL, считайте ядра.

Сравнение стоимости — когда что выгоднее

Давайте посчитаем на реальных примерах. Цены приблизительные (актуальные смотрите на keytrust24.store), но пропорции верные.

Сценарий 1: маленькая компания

Сервер с одним 4-ядерным процессором. 10 пользователей. Только внутренний доступ.

По ядрам: 4 ядра = 2 пакета 2-Core Pack Standard. По CAL: 1 серверная лицензия + 10 User CAL.

Для 10 пользователей модель CAL почти всегда дешевле. Иногда в два раза.

Сценарий 2: средняя компания

Сервер с двумя 12-ядерными процессорами (24 ядра). 60 пользователей. Только внутренний доступ.

По ядрам: 24 ядра = 12 пакетов 2-Core Pack. По CAL: 1 серверная лицензия + 60 User CAL.

Тут нужно считать конкретно. Порог безубыточности для типичных цен — где-то 40-60 пользователей. При 60 уже может быть примерно одинаково или ядра чуть дешевле.

Сценарий 3: веб-приложение

8-ядерный сервер. 5000 пользователей через веб. Server + CAL невозможен (невозможно отследить и купить CAL на каждого посетителя). Только ядра: 4 пакета 2-Core Pack.

Если честно, для веб-сценариев модель по ядрам — не просто выгоднее, а единственный вариант. И это логично: зачем считать людей, когда можно посчитать ядра?

Виртуализация SQL Server — отдельные правила

Половина всех SQL Server в мире работает на виртуалках. И правила лицензирования тут свои.

SQL Server Standard на виртуальной машине

Лицензируются виртуальные ядра (vCPU), назначенные ВМ. Минимум 4 vCPU. Каждая ВМ лицензируется отдельно.

На самом деле, это может быть выгодно. Вместо лицензирования 40 физических ядер хоста, вы создаёте ВМ с 8 vCPU и лицензируете только 8. Экономия в 5 раз, серьёзно.

SQL Server Enterprise на виртуальной машине

Enterprise даёт два варианта. Первый — лицензировать vCPU каждой ВМ (как Standard). Второй — лицензировать все физические ядра хоста и получить право на неограниченное количество ВМ с SQL Server Enterprise.

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

Кстати, при лицензировании всего хоста Enterprise вы ещё получаете License Mobility — можете перемещать ВМ между хостами в серверной ферме без перелицензирования. С Software Assurance, конечно.

-- Проверить, работает ли SQL Server на виртуальной машине
-- полезно когда готовишься к аудиту
SELECT virtual_machine_type_desc,
       softnuma_configuration_desc,
       socket_count,
       cores_per_socket,
       numa_node_count
FROM sys.dm_os_sys_info;

Software Assurance — нужна или нет

SA стоит примерно 25-30% от стоимости лицензии ежегодно. Звучит дорого? Давайте разберёмся, что вы за это получаете.

• Бесплатный апгрейд до новых версий SQL Server (вышел 2025 — обновляетесь бесплатно)
• License Mobility — перемещение лицензий между серверами без ожидания 90 дней
• Права на пассивный failover сервер без дополнительной лицензии
• Azure Hybrid Benefit — использование лицензий в облаке Azure
• Обучающие ваучеры и расширенная поддержка

Ну и тут надо считать по-честному. Если вы обновляете SQL Server каждые 3 года, SA почти наверняка окупается за счёт бесплатного апгрейда. Если сидите на одной версии 6-7 лет (а многие так делают), SA за это время обойдётся дороже, чем покупка новой лицензии.

А ещё важный момент: SA нужно приобретать в течение 90 дней после покупки новой лицензии. Пропустили окно — всё, нужно покупать новую лицензию целиком, чтобы к ней добавить SA. Неприятный сюрприз.

Standard vs Enterprise — когда переплата за Enterprise оправдана

Тут такое дело. Разница в цене между Standard и Enterprise огромная — Enterprise стоит в 4-5 раз дороже. Но иногда он реально нужен.

У Андрея (HP ProLiant DL380 Gen10, 2x Xeon Silver 4214, 24 ядра, 256 ГБ RAM) была показательная ситуация. Начинал с SQL Server Standard. Всё работало, пока база не выросла до 500 ГБ. Standard не мог использовать больше 128 ГБ RAM для буферного пула, запросы тормозили. Always On Basic позволял реплицировать только одну базу, а у них их было пять. Онлайн-перестроение индексов недоступно — каждое обслуживание требовало простоя.

Если честно, для большинства малых и средних компаний Standard хватает. Enterprise нужен когда: база больше 100 ГБ и растёт, нужна репликация нескольких БД, требуется high availability без простоев, или нагрузка требует больше 24 ядер.

Подводные камни при лицензировании

Вот список ошибок, которые я вижу постоянно. Буквально каждый второй клиент наступает на одни и те же грабли.

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

Ошибка 2: забывают про минимум 4 ядра на процессор. Двухъядерный процессор? Всё равно лицензируете 4 ядра. Бывает на старых серверах.

Ошибка 3: не учитывают второй процессор. На двухпроцессорном сервере нужно лицензировать ядра обоих процессоров. Даже если SQL Server через affinity mask привязан к одному.

Ошибка 4: путают SQL Server CAL и Windows Server CAL. Это разные продукты! Нужны оба комплекта. SQL Server CAL не даёт доступ к Windows Server и наоборот.

Ошибка 5: используют Developer Edition на проде. SQL Server Developer бесплатен и функционально идентичен Enterprise. Соблазн велик. Но лицензия разрешает только разработку и тестирование. Поставили на прод — нарушение, штрафы при аудите.

Знаете что? Шестая ошибка встречается реже, но обходится дорого. Люди покупают CAL для SQL Server 2019, а потом обновляют сервер до SQL Server 2022. CAL версии 2019 не дают доступ к 2022. Нужно либо покупать новые CAL, либо иметь SA.

SQL Server Express и Developer — бесплатные альтернативы

Не всегда нужно платить. Серьёзно.

SQL Server Express — полностью бесплатен для продакшена. Ограничения: максимум 1 ГБ RAM для буферного пула, размер базы до 10 ГБ, 4 ядра. Для небольших приложений, сайтов на WordPress (да, бывает и такое), мелких баз — вполне рабочий вариант.

SQL Server Developer — бесплатен, функционально идентичен Enterprise, но только для разработки и тестирования. На проде использовать нельзя. Отличная штука для dev-среды.

На самом деле, многие проекты начинают с Express и переходят на Standard только когда база перерастает 10 ГБ. Экономия на старте бывает существенной.

Лицензирование отказоустойчивых конфигураций

Если у вас кластер или Always On AG, правила зависят от типа реплики.

Пассивная реплика (не обслуживает запросы, только принимает данные для failover) может быть бесплатной — но только при наличии Software Assurance на активном сервере. Standard с SA даёт право на одну пассивную реплику. Enterprise с SA — неограниченное количество.

Активная вторичная реплика (readable secondary, обслуживает SELECT-запросы) лицензируется полностью. Как отдельный сервер. Без скидок.

Грубо говоря, если вы строите кластер из трёх серверов, где один активный, один пассивный (failover) и один readable secondary, вам нужны: полная лицензия на активный, SA на активный (для бесплатного пассивного), полная лицензия на readable secondary. Итого две полных лицензии плюс SA.

SQL Server в облаке — сравнение с on-premise

Кстати, всё чаще спрашивают: может, проще не покупать лицензии, а взять Azure SQL Database или SQL Server на AWS RDS? Короче, зависит от нагрузки и горизонта планирования.

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

On-premise выгоднее, когда: нагрузка стабильная 24/7, есть своё железо и админы, горизонт планирования 3-5 лет. За 3 года аренда в облаке обычно обходится дороже, чем покупка собственных лицензий.

А ещё есть Azure Hybrid Benefit — если у вас есть лицензии SQL Server с SA, можно использовать их в Azure и платить только за вычислительные ресурсы, без стоимости лицензии. Неплохая экономия.

Ну и если вы решили покупать on-premise лицензии, на keytrust24.store есть SQL Server Standard и Enterprise с моментальной доставкой ключа. Без ожидания, без коробок, ключ приходит на email сразу после оплаты.

Пошаговый алгоритм выбора модели

Давайте по порядку. Вот как определить оптимальную модель для вашей конкретной ситуации:

1. Определите, нужен Standard или Enterprise. Если Enterprise — только ядра, дальше не читайте
2. Определите тип доступа. Есть внешние пользователи (через сайт, API, мобильное приложение)? Тогда только ядра
3. Посчитайте количество физических ядер на сервере (или vCPU, если виртуалка)
4. Посчитайте количество пользователей или устройств, которым нужен доступ
5. Рассчитайте стоимость обоих вариантов по актуальным ценам
6. Учтите рост на 2-3 года. Если пользователей станет в два раза больше, CAL может стать невыгодной

По факту, эмпирическое правило такое: до 25-30 пользователей на стандартном сервере (16-24 ядра) обычно выгоднее CAL. Больше 50-60 пользователей — выгоднее ядра. Промежуток 30-50 нужно считать конкретно.

Версии CAL и правила даунгрейда

CAL привязаны к версии SQL Server. Вот правила совместимости:

• CAL для SQL Server 2022 дают доступ к 2022 и всем предыдущим версиям
• CAL для SQL Server 2019 дают доступ только к 2019 и ниже (не к 2022)
• При обновлении сервера проверяйте, что CAL соответствуют новой версии
• SA на CAL даёт автоматическое обновление при выходе новой версии

Тут такое дело — многие покупают лицензию SQL Server 2022, а потом выясняют, что их CAL от 2017 года не подходят. Приходится докупать. Обратите на это внимание, если обновляетесь с более старой версии.

А ещё — лицензия SQL Server 2022 позволяет установить и использовать 2019, 2017 и более ранние версии (право на даунгрейд). Бывает полезно, когда приложение не сертифицировано под новую версию. Лицензия Enterprise даёт право запускать Standard, но не наоборот.

Аудит лицензий SQL Server — что проверяют и как подготовиться

Знаете что? Аудиты Microsoft — это не страшилка. Это реальность, особенно для компаний с более чем 50 компьютерами. Microsoft имеет право запросить проверку лицензионного соответствия, и отказаться нельзя — это прописано в лицензионном соглашении.

Что проверяют при аудите:

• Количество установленных экземпляров SQL Server и их редакции
• Количество физических ядер на каждом сервере
• Наличие и версии CAL (если используется модель Server+CAL)
• Соответствие редакции Developer/Express условиям использования
• Виртуальные машины — сколько их, сколько vCPU назначено
• Мультиплексинг — реальное количество конечных пользователей

У Лёши (Supermicro SuperServer, 2x Xeon E5-2680 v4, 28 ядер, 192 ГБ RAM) был опыт прохождения аудита. Компания использовала SQL Server Standard по модели CAL. Аудиторы попросили скрипт для сбора информации, запустили его на всех серверах, сверили с документами. Выяснилось, что на одном из серверов стоял SQL Server Developer, который использовался для продакшен-базы отчётности. Нарушение. Пришлось доплатить за полноценную лицензию Standard и заплатить пени.

Если честно, лучший способ подготовиться к аудиту — вести учёт лицензий постоянно. Заведите таблицу: сервер, количество ядер, редакция SQL Server, модель лицензирования, количество CAL, даты покупки, наличие SA. Обновляйте при каждом изменении.

-- Скрипт для инвентаризации SQL Server
-- запускайте на каждом экземпляре перед аудитом
SELECT SERVERPROPERTY('MachineName') AS server_name,
       SERVERPROPERTY('Edition') AS edition,
       SERVERPROPERTY('ProductVersion') AS version,
       SERVERPROPERTY('ProductLevel') AS service_pack,
       (SELECT cpu_count / hyperthread_ratio FROM sys.dm_os_sys_info) AS physical_cores,
       (SELECT cpu_count FROM sys.dm_os_sys_info) AS logical_cpus;

Рекомендации для типичных сценариев

На keytrust24.store можно найти лицензии SQL Server Standard и Enterprise, а также CAL-лицензии по адекватным ценам. Ключ активации приходит моментально, не нужно ждать поставку коробки.

Итоговые рекомендации — что запомнить

Вот в чём прикол с лицензированием SQL Server — кажется сложным, но на самом деле сводится к трём вопросам. Какая редакция нужна? Кто и сколько людей будет подключаться? Есть ли внешний доступ к базе?

Enterprise — только ядра, без вариантов. Standard с внешними пользователями — тоже только ядра. Standard с фиксированным числом внутренних пользователей — считайте оба варианта, обычно CAL выгоднее при малом числе людей.

Не забывайте про рост. Купить ядра один раз и не думать о количестве пользователей бывает спокойнее, чем докупать CAL каждый раз при найме нового сотрудника. А ещё помните про SA — она окупается, если вы обновляетесь каждые 2-3 года, и не окупается, если сидите на одной версии 5+ лет.

Ну и главное — не экономьте на лицензиях, ставя Developer или Express на продакшен, когда нужен Standard. Штрафы при аудите обойдутся дороже. Купите правильную лицензию сразу и работайте спокойно.