Лицензирование Windows Server считают до выбора сервера

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

У расчета две независимые оси. Лицензии Core дают право запускать серверное ПО на конкретном оборудовании или, при специальных условиях, лицензировать отдельные виртуальные машины. CAL дают пользователям или устройствам право обращаться к этому ПО. Покупка одного не заменяет другое. Ни установленный гипервизор, ни маленькая нагрузка, ни один домен не отменяют эту схему.

Дальше я использую правила физического лицензирования Windows Server Standard и Datacenter и отдельно отмечаю вариант лицензирования по виртуальным машинам. Это расчет для подготовки закупки, а не замена Product Terms и условий конкретного соглашения Microsoft. В финальную спецификацию всегда надо подставить редакцию, версию, канал закупки и права Software Assurance или подписки.

Ядра и CAL закрывают разные права

Лицензии на ядра покрывают вычислительный хост, а CAL покрывают доступ людей и устройств к серверным службам. Эти величины нельзя складывать в одну строку «лицензии Windows Server» без расшифровки.

При лицензировании по физическим ядрам Standard и Datacenter назначают лицензии физическому серверу. Считают все физические ядра во всех установленных процессорах с учетом минимумов. Количество vCPU у гостевых машин не уменьшает эту базу. Отключенное в BIOS ядро тоже не исчезает из расчета: Microsoft прямо отвечает на этот вопрос в FAQ по лицензированию Windows Server и требует покрывать все физические ядра.

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

Доступ бывает прямым и косвенным. Если сотрудник открывает внутреннее приложение, а оно через промежуточный сервис читает SQL, каталог или файлы на Windows Server, промежуточный слой обычно не сокращает число требуемых лицензий доступа. В документах Microsoft эта ситуация называется multiplexing. Считать только учетную запись технического сервиса опасно: лицензирование смотрит на людей или устройства, которые получают доступ к серверным функциям через эту цепочку.

Полезно держать в смете три отдельные группы:

• Core для каждого физического хоста и каждого слоя Standard;
• базовые Windows Server CAL для пользователей и устройств;
• дополнительные лицензии доступа, например RDS CAL, если используются соответствующие функции.

Так закупщик видит, откуда взялось каждое число, а архитектор может проверить его при изменении конфигурации.

Минимумы меняют счет даже на малом сервере

Физический сервер надо лицензировать по фактическим ядрам, но не меньше восьми ядер на процессор и шестнадцати ядер на сервер. Работают оба ограничения одновременно.

Формулу для одного хоста удобно записать так:

лицензируемые ядра =
max(16, сумма по процессорам max(8, физические ядра процессора))

Однопроцессорный сервер с 6 ядрами требует 16 Core, потому что срабатывает серверный минимум. Однопроцессорный сервер с 12 ядрами тоже требует 16. Два процессора по 6 ядер дают не 12, а 16: каждый процессор доводится до восьми, после чего серверный минимум уже выполнен. Два процессора по 12 ядер дают 24 Core. Два процессора по 24 ядра дают 48 Core.

Microsoft продает лицензии Core пакетами по два ядра и, как удобный вариант, пакетами по шестнадцать. Пакет 16 Core не означает «лицензия на сервер». Это просто комплект из шестнадцати лицензий на ядро. Для хоста с 24 ядрами подойдут один пакет 16 Core и четыре пакета 2 Core. Для хоста с 26 ядрами нужны один пакет 16 Core и пять пакетов 2 Core. Нельзя округлить 26 до 24 из-за размера упаковки.

Есть и обратная ошибка: закупать два пакета 16 Core для любого двухпроцессорного сервера. Число процессоров само по себе не требует по одному 16-ядерному комплекту на сокет. Два процессора по 8 ядер укладываются в 16 Core на сервер. Два процессора по 18 ядер требуют 36 Core, то есть, например, два пакета 16 Core и два пакета 2 Core.

Перед запросом цены снимите данные не из коммерческого названия процессора, а из утвержденной спецификации хоста. Нужны число установленных процессоров и число физических ядер в каждом. Потоки, логические процессоры и Hyper-Threading в эту формулу не входят. Запасные пустые сокеты тоже не считаются, пока в них нет процессоров, но последующая установка CPU изменит лицензионную потребность.

На работающем Windows-хосте исходные числа можно быстро проверить через PowerShell:

Get-CimInstance Win32_Processor |
  Select-Object DeviceID, NumberOfCores, NumberOfLogicalProcessors

Для двух 12-ядерных процессоров результат по форме будет таким:

DeviceID NumberOfCores NumberOfLogicalProcessors
CPU0                12                        24
CPU1                12                        24

В расчет идет столбец NumberOfCores: 12 плюс 12 дает 24. Столбец NumberOfLogicalProcessors помогает заметить включенную многопоточность, но складывать 24 плюс 24 и покупать 48 Core для этого примера не надо. Команду стоит выполнить на каждом физическом узле и сохранить вывод с датой, потому что одинаковые модели серверов иногда приходят с разной комплектацией CPU.

У команды есть предел: она показывает установленное оборудование, но не доказывает коммерческие права и не объясняет, сколько ВМ может принять хост. Сверьте вывод с заказной спецификацией и настройками управления кластером. Если инвентаризация показывает один CPU, а в спецификации два, выясните причину до расчета: второй процессор может быть еще не установлен, отключен из-за неисправности или неверно виден системе. Лицензионную базу нельзя выбирать по самому удобному из противоречащих источников.

Standard оплачивается полными слоями

Один полный слой Windows Server Standard покрывает все физические ядра хоста и дает право запустить до двух виртуальных операционных сред Windows Server. Для следующих двух ВМ надо еще раз покрыть все ядра того же хоста.

Это место часто считают неверно. Покупатель видит шесть гостевых систем по 4 vCPU и заказывает 24 Core. При физической модели vCPU не участвуют в расчете. Если у хоста 24 физических ядра, один слой равен 24 Core независимо от размера ВМ. Для шести ВМ нужны три слоя, то есть 72 Core, назначенные этому хосту.

Формула для Standard при физическом лицензировании выглядит так:

слои Standard = ceil(максимум Windows Server ВМ на хосте / 2)
Core Standard на хост = лицензируемые ядра хоста * слои

Для одной ВМ все равно нужен один полный слой. Для двух ВМ нужен один слой. Третья ВМ переводит расчет на два слоя, которые разрешают до четырех ВМ. Пятая требует третий слой, который разрешает до шести. Неиспользованное место в паре не переносится на другой сервер.

Право на физическую операционную среду надо трактовать аккуратно. Когда физический экземпляр Windows Server используют только для размещения и управления виртуальными средами, правила дают соответствующее право хоста. Если на нем одновременно запускают обычную рабочую нагрузку, например файловую службу или прикладную систему, физический экземпляр занимает одно из разрешенных окружений. Поэтому хороший проект оставляет родительскую среду Hyper-V только для управления виртуализацией.

Datacenter после полного покрытия физических ядер разрешает неограниченное число виртуальных операционных сред Windows Server на этом хосте. Это не делает Datacenter автоматически дешевле. Сравнивать надо цены конкретного соглашения и ожидаемый максимум ВМ на каждом хосте. Microsoft в FAQ приводит ориентир, что для 13 и более OSE рекомендуют Datacenter, но порог покупки нельзя превращать в универсальную цену отсечения: скидки, редакции, Step-Up и состав контракта меняют экономику.

В кластере лицензируют возможное размещение

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

Представим два хоста, на каждом обычно работают три гостевые Windows Server. Во время обслуживания первого хоста все шесть ВМ переходят на второй. Если купить по два слоя Standard на хост, обычный режим по три ВМ будет покрыт: два слоя разрешают до четырех. Но режим обслуживания нарушит предел на принимающем хосте. Для разрешенного переноса всех шести ВМ каждый узел надо покрыть тремя слоями Standard.

Нельзя исправить это общей кучей из шести слоев с расчетом «по три слоя где нужно». Лицензии назначаются серверам. Общие правила Microsoft ограничивают переназначение бессрочных лицензий между устройствами сроком в 90 дней, кроме предусмотренных исключений. Плановые миграции и автоматический failover происходят чаще и не должны зависеть от ручного переназначения.

Практический расчет должен исходить из настроенных ограничений кластера:

• если любая ВМ может работать на любом хосте, каждый хост покрывают под полный возможный набор;
• если группы ВМ жестко закреплены правилами affinity и технически не смогут собраться на одном узле, можно считать по документированному максимуму каждого узла;
• если для аварийного режима часть ВМ выключается, список и порядок отключения надо закрепить, а не подразумевать;
• если узел холодного резерва может запустить рабочие ВМ, сам ярлык «резервный» не дает ему лицензионного освобождения.

У клиентов с активной Software Assurance или подписочными лицензиями доступен отдельный путь: лицензирование по виртуальным машинам в рамках Flexible Virtualization Benefit. Тогда считают виртуальные ядра каждой ВМ, минимум восемь на ВМ, а лицензии получают расширенные права перемещения в пределах серверной фермы. Этот вариант нельзя молча применять к обычным бессрочным лицензиям без Software Assurance. В закупочном расчете его следует вынести отдельным сценарием и проверить права по соглашению.

User CAL и Device CAL выбирают по реальной работе

User CAL выгоднее и понятнее, когда один сотрудник использует несколько устройств, а Device CAL подходит для общего компьютера, за которым работают разные сотрудники. Выбирать один тип на всю организацию не обязательно: Microsoft разрешает сочетать User CAL и Device CAL.

Сначала нарисуйте границу доступа. Считайте не штатную численность компании, а всех внутренних пользователей и устройства, которые прямо или косвенно обращаются к Windows Server. Учетные записи администраторов тоже принадлежат людям. Сервисные учетные записи не заменяют CAL конечных пользователей. Одновременно работающие сессии здесь не помогают: обычная Windows Server CAL не считается по concurrency.

Пример с офисом и сменной площадкой:

• 25 офисных сотрудников работают с ноутбука и иногда с домашнего компьютера;
• 60 сменных сотрудников используют только 20 закрепленных общих терминалов;
• офисные сотрудники не входят через терминалы площадки, а сменные сотрудники не используют другие устройства;
• серверы обслуживают обе группы.

Рациональная комбинация дает 25 User CAL для офисных сотрудников и 20 Device CAL для общих терминалов. Покупка только User CAL потребовала бы 85 лицензий. Покупка только Device CAL потребовала бы пересчитать все офисные устройства и, вероятно, дала бы число больше 45. Смешанная модель работает лишь пока граница правдива. Если мастер смены начнет заходить с личного ноутбука, его надо покрыть User CAL или отдельно лицензировать это устройство.

Версия CAL тоже имеет значение. CAL новой версии разрешает доступ к этой и более ранним версиям Windows Server. CAL старой версии не дает право обращаться к более новой серверной версии. Право downgrade у серверной лицензии не исправляет недостаточную версию CAL. В ведомости стоит отдельно записать версию серверных Core и версию CAL, даже если поставщик показывает их одной коммерческой строкой.

Для внешних пользователей действует другой выбор. Можно назначать им CAL по пользователям или устройствам либо приобрести Windows Server External Connector на каждый физический сервер, к которому они обращаются, если условия подходят. Сотрудников, а также определенных подрядчиков на площадке заказчика нельзя просто объявить внешними пользователями ради EC. Здесь особенно важны определения из Product Terms.

RDS CAL добавляется поверх базовой CAL

Доступ к полноценным сеансам Remote Desktop Services требует RDS CAL в дополнение к обычной Windows Server CAL. Административное подключение для управления сервером и рабочий удаленный стол сотрудников нельзя смешивать в одной категории.

Если 30 сотрудников запускают приложения на RD Session Host, им нужны базовые Windows Server CAL и соответствующие RDS CAL. Выбор Per User или Per Device надо согласовать с режимом развертывания и реальным доступом. Microsoft Learn отдельно указывает, что для RD Session Host в рабочей группе разрешен режим Per Device, а Per User там не допускается. В доменной среде доступны оба режима.

RDS CAL устанавливают и выдают через активированный сервер лицензирования Remote Desktop. Это технический контроль для RDS, но наличие записей в диспетчере лицензирования не заменяет закупочную ведомость и права по договору. Для обычных Windows Server CAL нет аналогичного сервера, который сам посчитает всех пользователей файловых, печатных, DNS или прикладных служб.

Не всякое соединение по RDP означает покупку RDS CAL. Product Terms предусматривают административный доступ для ограниченного числа пользователей к экземплярам сервера, но использовать этот режим как дешевую замену рабочему терминальному серверу нельзя. Если пользователь получает рабочий стол или приложение для выполнения своей обычной работы, закладывайте RDS CAL и проверяйте точные условия версии.

Расчет двух хостов проверяется в четыре строки

Возьмем конфигурацию, которую можно положить в приложение к заявке. Есть два одинаковых хоста, в каждом установлено два процессора по 12 физических ядер. Кластер запускает шесть ВМ с Windows Server. Любая ВМ может перейти на любой хост, а во время обслуживания один хост принимает все шесть. Еще две ВМ работают под Linux и не требуют прав на запуск Windows Server, поэтому они не увеличивают число слоев Standard.

База одного хоста равна 24 Core: два процессора по 12 ядер превышают минимум восемь на процессор, а итог превышает минимум шестнадцать на сервер.

Для Standard на каждом хосте нужен максимум шесть Windows Server ВМ. Шесть делим на два и получаем три полных слоя. Один хост требует 24 * 3 = 72 Core Standard. Два хоста требуют 72 * 2 = 144 Core Standard.

Упаковку можно записать без округления:

На один хост: 4 x 16 Core + 4 x 2 Core = 72 Core
На два хоста: 8 x 16 Core + 8 x 2 Core = 144 Core

Это один из вариантов разложения по пакетам. Можно собрать все из 2 Core, если коммерческая программа и цена делают это разумным. Важна сумма назначенных лицензий на ядро, а не красота упаковки.

Для Datacenter каждый хост покрывают один раз: 24 Core * 2 хоста = 48 Core Datacenter. Упаковка на два хоста может выглядеть как два пакета 16 Core и восемь пакетов 2 Core. После полного покрытия Datacenter разрешает неограниченное число Windows Server ВМ на этих хостах, поэтому режим обслуживания уже не добавляет слои.

Теперь добавим доступ из предыдущего примера. Организации нужны 25 Windows Server User CAL и 20 Windows Server Device CAL. Если те же люди работают через RD Session Host, к базовым CAL добавляют 25 RDS User CAL и 20 RDS Device CAL при условии, что выбранная схема поддерживается развертыванием и точно описывает доступ. Если RDS использует только часть групп, дополнительные CAL считают только для этой части, но базовые CAL остаются.

Итоговые сравниваемые варианты:

Вариант A: 144 Core Standard
Вариант B: 48 Core Datacenter
Доступ в обоих вариантах: 25 User CAL + 20 Device CAL
RDS при необходимости: отдельные RDS CAL поверх базовых

Числа Core нельзя сравнивать между редакциями как одинаковые по цене единицы. Запросите стоимость обоих вариантов у поставщика по одному каналу и одной версии. Затем добавьте ожидаемый рост ВМ. Если через год максимум станет восемь Windows Server ВМ на хост, Standard потребует четвертый слой: еще 24 Core на каждый хост.

Спецификация должна пережить смену конфигурации

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

Для каждого хоста запишите модель роли, число установленных CPU, физические ядра на CPU, лицензионную базу Core, максимум Windows Server OSE и выбранную редакцию. Для Standard добавьте число слоев. Для кластера укажите, что происходит при обслуживании одного узла и при отказе. Для CAL приложите две непересекающиеся группы пользователей и устройств с описанием границ доступа.

Минимальная рабочая таблица выглядит так:

HOST-01 | 2 CPU | 12 cores/CPU | base 24 | max WS OSE 6 | Standard layers 3 | Core 72
HOST-02 | 2 CPU | 12 cores/CPU | base 24 | max WS OSE 6 | Standard layers 3 | Core 72
CAL-U   | office users 25      | Windows Server User CAL 25
CAL-D   | shared devices 20    | Windows Server Device CAL 20

Отдельно зафиксируйте версию, тип лицензии, наличие Software Assurance или подписки, право downgrade, необходимость RDS и внешний доступ. Не подменяйте эти поля фразой «лицензия последней версии». Коммерческие программы меняются, а право использования определяется не установочным образом и не ключом активации.

В Казахстане GSE поставляет и интегрирует ПО Microsoft вместе с серверной инфраструктурой, поэтому расчет ядер, режим виртуализации и состав CAL можно сверить до фиксации аппаратной спецификации. Такая сверка полезна именно до заказа: переход с двух 12-ядерных CPU на два 16-ядерных увеличит не только один базовый комплект, но каждый слой Standard на обоих хостах.

Я обычно прошу подписать расчет у трех владельцев данных: инфраструктура подтверждает железо и миграции, владелец приложений подтверждает число Windows Server ВМ и RDS, закупка подтверждает программу лицензирования. Юрист или специалист по лицензиям сверяет определения с Product Terms. Это не бюрократический круг: каждый из них отвечает за множитель, который остальные не контролируют.

Активация не доказывает достаточность лицензий

Ключ продукта и успешная активация показывают, что экземпляр ПО активирован, но не подтверждают, что организация купила достаточно Core и CAL. Техническая система не знает все условия договора, косвенный доступ и возможное размещение ВМ в кластере.

Сохраните расчет как часть конфигурационной документации. К нему нужны счета и подтверждения прав, схема кластера, выгрузка физических CPU и ядер, список ВМ с ОС, правила перемещения, перечень групп доступа и объяснение выбора User или Device CAL. Для RDS добавьте режим лицензирования и данные сервера лицензий.

Пересчет нужен при событиях, а не по календарному ритуалу. Его запускают замена или добавление процессора, рост числа Windows Server ВМ, новый узел, изменение правил failover, обновление версии, запуск RDS, появление внешних пользователей, смена программы закупки или окончание Software Assurance. Изменение только объема RAM или дисков само по себе не меняет Core, но часто сопровождает рост виртуализации, который меняет слои Standard.

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

Последняя проверка проста. Возьмите один самый нагруженный или принимающий хост и попробуйте восстановить его число Core без устных пояснений, только по таблице. Затем выберите одного сотрудника и одно общее устройство и покажите, какой CAL покрывает каждый путь доступа. Если обе цепочки прослеживаются до SKU и условия договора, смету можно отдавать в закупку.