Лицензирование Windows Server Standard и Datacenter: примеры

Зачем сравнивать Standard и Datacenter

Покупка Windows Server для виртуализации обычно сводится к простой задаче: запустить нужное число виртуальных машин (ВМ) и не переплатить. Сложность в том, что стоимость зависит не только от редакции, но и от того, как устроены хосты, будут ли миграции и сколько ВМ реально окажется на каждом узле в обычный день и при аварии.

Главное отличие Standard и Datacenter - права на виртуализацию. Обе редакции лицензируются по физическим ядрам хоста, но Standard дает ограниченное число прав на ВМ и требует «наращивания слоями», а Datacenter после лицензирования ядер снимает лимит по числу ВМ. Поэтому практический вопрос всегда один: сколько ВМ будет на каждом хосте сейчас и сколько станет через 6-12 месяцев.

Чтобы расчет не оказался «на глаз», заранее зафиксируйте исходные данные: сколько физических ядер на каждом хосте, одинаковые ли узлы в кластере, сколько хостов в схеме, будут ли миграции, сколько ВМ планируется сейчас и какой рост ожидается, а также будет ли хост работать только как гипервизор или на нем нужны роли самой ОС.

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

Ниже - правила подсчета по ядрам и права на ВМ для сценариев с 1, 2 и 4 хостами. CAL (клиентские лицензии доступа), RDS CAL и лицензирование сторонних продуктов вынесены за скобки, чтобы не смешивать разные строки бюджета.

Базовые правила: как Windows Server считается по ядрам

Windows Server Standard и Datacenter лицензируются не «по серверу» и не «по сокетам», а по физическим ядрам на каждом хосте, где будет запускаться виртуализация. Поэтому стартовая точка любого расчета - точное число физических ядер в конкретном железе.

Считаются именно физические ядра CPU. Само по себе количество сокетов (1 или 2) для лицензирования ничего не решает: важна итоговая сумма ядер в системе.

Есть минимумы, которые часто забывают. Даже если ядер меньше, лицензировать нужно минимум:

• 8 ядер на каждый процессор
• 16 ядер на каждый сервер

Из этого следует практическое правило: сервер с 1 CPU на 6 ядер все равно лицензируется как 16 ядер. Сервер с 2 CPU по 6 ядер (итого 12) тоже лицензируется как 16.

Лицензии обычно покупают «шагами» по 2 ядра. На практике вы закрываете минимум (16 ядер) базовым набором и докупаете 2-ядерные пакеты до фактического числа ядер. Например, хост на 24 ядра = 16 ядер + еще 8 ядер (четыре пакета по 2).

Эти правила одинаковы для Standard и Datacenter. Разница начинается там, где вы привязываете лицензирование хоста к правам на запуск ВМ.

Права на виртуальные машины: Standard vs Datacenter простыми словами

Лицензируется не виртуальная машина, а физический хост и право запускать на нем определенное число ВМ Windows Server. Поэтому в расчетах всегда две части: сколько ядер у сервера и сколько ВМ вы планируете держать на каждом узле.

Standard: после того как вы полностью лицензировали все физические ядра хоста (с учетом минимумов), вы получаете право запустить до 2 ВМ Windows Server на этом хосте.

Если нужно больше двух ВМ, включается «стэкинг»: вы повторно лицензируете те же ядра того же хоста. Каждый полный повтор добавляет права еще на 2 ВМ. То есть рост идет парами ВМ, а оплата - за повторное покрытие всех ядер.

Datacenter: вы также лицензируете все ядра хоста, но затем получаете право запускать неограниченное число ВМ Windows Server на этом сервере.

Короткая шпаргалка:

• Standard: 1 полностью лицензированный хост = права на 2 ВМ, дальше +2 ВМ за каждый повтор лицензирования ядер.
• Datacenter: 1 полностью лицензированный хост = права на любое число ВМ.

Пример: если на одном хосте планируется 6 ВМ Windows Server, в Standard потребуется 3 «круга» (2+2+2) лицензирования всех ядер. В Datacenter - один «круг» без лимита.

Пошаговый алгоритм расчета лицензий для виртуализации

Удобнее считать по каждому хосту отдельно, а затем суммировать и сравнивать редакции. Это одинаково хорошо работает и для одиночного сервера, и для кластера.

1) Считаем ядра на каждом хосте

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

2) Переводим ядра в наборы лицензий

Дальше все сводится к 2-ядерным пакетам: сколько ядер нужно покрыть на хосте, столько и покупаете (с округлением вверх, если получилось нечетное число).

3) Определяем, сколько ВМ реально окажется на хосте

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

4) Для Standard считаем «слои» прав на ВМ

В Standard один полностью лицензированный хост дает право на 2 ВМ. Если нужно больше, добавляются слои:

• ВМ на хост / 2 = сколько слоев нужно (округлять вверх)
• лицензии на ядра для хоста x количество слоев = итог по Standard

5) Сравниваем с Datacenter

В Datacenter ядра покрываются один раз на хост, и дальше лимита по ВМ нет. Если для Standard получается много слоев (часто 3-4 и выше) или рост ВМ трудно предсказать, Datacenter обычно проще в учете и спокойнее при изменениях.

Пример 1: один хост виртуализации (1 сервер)

Возьмем один физический сервер под Hyper-V (или другой гипервизор). Допустим, в нем 2 CPU по 12 ядер, итого 24 ядра. Минимумы лицензирования здесь не влияют, считаем реальные 24.

Исходные данные

Ключевые параметры - ядра и число ВМ:

• Хост: 24 физических ядра (лицензируем все 24).
• Standard: 2 ВМ за один комплект лицензий, покрывающий все ядра.
• Datacenter: неограниченное число ВМ после лицензирования всех ядер.

Сценарий А: нужно 2 ВМ

Если нужны 2 ВМ (например, AD/DNS и файловый сервер), Standard обычно выглядит рационально: один раз лицензируете 24 ядра и получаете права на 2 ВМ.

Datacenter в этом сценарии тоже подходит, но чаще его выбирают, когда ожидается много ВМ или быстрый рост.

Сценарий Б: нужно 6-10 ВМ

Здесь включается стэкинг Standard: каждые дополнительные 2 ВМ требуют еще один комплект Standard на те же 24 ядра.

Пример для 8 ВМ:

• 1 комплект Standard (24 ядра) = 2 ВМ
• нужно 8 ВМ = 4 комплекта Standard (по 24 ядра каждый)

На этом уровне Datacenter становится проще считать: один раз лицензируете 24 ядра и добавляете ВМ без постоянного пересчета. Точка, где Datacenter становится выгоднее, зависит от цен и условий закупки, но часто она находится там, где Standard требует 3-4 комплекта и больше.

Практичный совет: закладывайте небольшой запас. Тестовая или резервная ВМ обычно появляется неожиданно. Если планируете 6 ВМ, считайте хотя бы 8.

Пример 2: два хоста (кластер, миграции, отказ одного узла)

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

Сценарий: 2 одинаковых хоста по 24 физических ядра каждый. Всего 10 ВМ. В обычный день они распределены по 5 ВМ на узел, включены миграции. При отказе одного узла все 10 ВМ должны подняться на оставшемся.

Для Standard права считаются слоями: один слой (полное лицензирование ядер хоста) = 2 ВМ на этом хосте. Значит, если в аварии один узел должен выдержать 10 ВМ, на каждом хосте нужно иметь права на 10 ВМ, то есть 5 слоев.

Расчет Standard по худшему случаю:

• 1 слой = лицензируем все 24 ядра и получаем право на 2 ВМ
• нужно 5 слоев на хост
• итог: 24 ядра x 5 слоев = «120 ядер лицензирования» на каждом из двух хостов

С Datacenter проще: по одному комплекту на 24 ядра для каждого хоста, дальше можно запускать любое число ВМ и спокойно мигрировать их между узлами.

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

Пример 3: четыре хоста (масштабирование и обслуживание без простоя)

Для 4 хостов типична схема, где есть общий пул ВМ, плановые миграции (обновления, профилактика) и требование не останавливать сервисы. В таком режиме снова важен максимум ВМ на узел при N-1, а не «средняя температура».

Пример: 4 одинаковых хоста, на каждом по 32 физических ядра (например, 2 CPU по 16). Всего в кластере 40 ВМ.

Как учитывать миграции и обслуживание

Если один хост уходит в обслуживание, остальные три временно принимают его ВМ. На практике используют один из двух подходов:

• Среднее размещение + запас: 40/4 = 10 ВМ на хост, затем фиксируют запас (например, до 12 ВМ на узел).
• N-1: один хост недоступен, значит 40/3 = 13-14 ВМ на узел, затем округляют вверх и фиксируют лимит (например, 16 ВМ максимум на хост).

Что это значит для Standard и Datacenter

Standard: 2 ВМ на хост за один полный комплект лицензий на все его ядра. При росте ВМ права наращиваются слоями.

Если по N-1 вы закладываете максимум 16 ВМ на хост, это 16/2 = 8 слоев. То есть на каждом из 4 хостов нужно покрыть все 32 ядра восемь раз. Это заметно и по бюджету, и по сопровождению.

Datacenter: ядра лицензируются один раз на хост, и лимита по ВМ нет. В кластере из 4 узлов это обычно проще в учете и спокойнее при росте плотности ВМ.

Частые развилки: разные ядра, разный рост, разные нагрузки

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

Неровные хосты по ядрам

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

Рост ВМ: не покупайте «впритык»

Если сейчас 6-8 ВМ, а через полгода станет 20, Standard легко превращается в регулярные докупки. Практичнее заложить рост на 12-18 месяцев и сравнить две цифры: «сейчас» и «план». Если в «плане» выходит много повторных покрытий на хостах, Datacenter обычно проще для согласований и дальнейшей эксплуатации.

Бывает и наоборот: ядер много, а ВМ мало и рост медленный (например, 2-4 стабильные ВМ на узел). Тогда Standard остается рациональным выбором даже для производительных серверов.

Помните, что расчет прав Windows Server не включает RDS CAL, SQL Server, антивирус, резервное копирование или лицензии гипервизора. Эти позиции считают отдельно, чтобы не смешивать «ядра и права на ВМ» с прикладными сервисами.

Для согласования закупки удобно фиксировать расчет в простой таблице: хост (модель и роль), ядра (и сокеты для справки), сколько «слоев» покрытий нужно для Standard, сколько ВМ разрешено и сколько планируется, выбранная редакция и причина, а также отдельные лицензии и подписки (RDS, SQL и т.д.). Если вы подбираете железо под рост, привязывайте расчет к конкретным конфигурациям, чтобы не пересчитывать все из-за изменения числа ядер.

Типовые ошибки и ловушки в расчетах

Промахи в лицензировании часто выглядят как «пара ядер туда-сюда» или «пару ВМ потом докупим», но в виртуализации это быстро выливается в лишние расходы или в ситуацию, когда часть среды формально не покрыта.

Чаще всего встречаются такие ошибки:

• Забывают минимум на сервер: даже если ядер меньше, лицензируется минимум 16 ядер на физический сервер.
• Считают права на ВМ, но не закрывают все физические ядра: в Standard права на ВМ появляются только после полного покрытия ядер хоста.
• В кластере берут среднее число ВМ на узел: корректнее считать аварийный режим и обслуживание (куда переедут ВМ, если узел недоступен).
• Берут Standard под десятки ВМ и получают «слоеный пирог» лицензий: много повторов, сложный учет, постоянные пересчеты при росте.
• Путают лицензии сервера и CAL: лицензия Windows Server не заменяет CAL для пользователей или устройств, а RDS CAL и другие зависимости считаются отдельно.

Практическое правило простое: сначала фиксируйте ядра каждого хоста, затем сценарий отказа и миграций, и только потом считайте, сколько слоев Standard нужно или с какого момента разумнее Datacenter.

Короткий чек-лист перед покупкой лицензий

Перед покупкой проверяйте не «среднее», а худший день: обслуживание или отказ узла, когда виртуальные машины временно уплотняются на оставшихся хостах.

• Сколько хостов виртуализации и сколько ядер на каждом (с учетом минимумов 8/16).
• Сколько ВМ максимум может оказаться на одном хосте в обычном режиме и в режиме N-1.
• Сколько слоев Standard понадобится на один хост (1 слой = 2 ВМ).
• Есть ли план роста на 12-36 месяцев и заложен ли запас.
• Соответствует ли выбранная редакция модели эксплуатации: живые миграции, обслуживание без простоя, временное уплотнение ВМ.

Пример для самопроверки: 2 хоста, по плану по 8 ВМ на каждом. Если один хост недоступен, все 16 ВМ должны поместиться на одном. В Standard права нужно считать по 16 ВМ на хост (8 слоев), даже если «обычно» на нем работало только 8.

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

Реалистичный сценарий: как выбрать редакцию под вашу организацию

Представим клинику или учебное заведение: 2-4 хоста виртуализации, планирование на 3-5 лет, число ВМ растет каждый год. Сегодня нужно 8-10 ВМ, через год станет 12-16, затем добавятся новые сервисы (например, телемедицина, электронный журнал, аналитика).

Типичный набор ВМ: контроллер домена, файловые сервисы, сервер приложений и база (часто 1С), отдельная ВМ под профильное ПО, плюс резервное копирование. Почти всегда появляются тестовые ВМ и временные машины на период миграций.

Вариантов обычно два:

Standard выбирают, если вы уверены, что на каждом хосте будет немного ВМ и рост ограничен. Тогда экономия на старте понятна, а докупки идут по мере расширения.

Datacenter выбирают, если виртуализация - базовая платформа, ВМ будет много или рост трудно предсказать. Здесь ценят не только экономику на горизонте, но и простоту: меньше пересчетов, меньше риска ошибиться при добавлении ВМ, спокойнее модернизации.

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

Чтобы решение не расползлось в процессе закупки, зафиксируйте его в одном документе: конфигурации хостов (ядра), выбранная редакция (Standard или Datacenter), лимит ВМ на хост и сценарий роста.

Следующие шаги: как быстро подготовить расчет и спецификацию

Точный расчет начинается с фактов. Ошибки почти всегда появляются из-за неточных исходных данных вроде «примерно 20 ВМ» или «кажется, 24 ядра». Удобнее сразу готовить два варианта (Standard и Datacenter), чтобы увидеть разницу не только по цене, но и по запасу на рост.

1) Соберите исходные данные (10-15 минут)

По каждому хосту запишите модель CPU и общее число физических ядер, сколько хостов есть сейчас и сколько планируется через 1-3 года, сколько ВМ будет на каждом хосте в обычном и аварийном режиме, какие ВМ будут на Windows Server, а какие на Linux или других ОС, и будет ли расширение (добавление CPU, рост числа ядер, покупка нового узла).

2) Сделайте два расчета и проверьте рост

Сравните Standard (ядра x количество слоев до нужного числа ВМ) и Datacenter (ядра один раз на хост). Отдельно посчитайте сценарий расширения: что будет, если добавится еще один хост или вы замените CPU на модель с большим числом ядер.

Ориентир: если сегодня у вас 12 ВМ на хост, а через год станет 25, Standard часто быстро догоняет Datacenter по стоимости из-за дополнительных слоев.

3) Подготовьте спецификацию закупки

В спецификацию обычно включают количество хостов, число ядер на каждом, выбранную редакцию, расчет прав на ВМ (включая аварийный режим) и небольшой запас на рост. Отдельной строкой зафиксируйте, что меняется при добавлении еще одного узла.

Если вы связываете закупку с поставкой железа и внедрением, удобнее, когда один подрядчик отвечает и за конфигурацию хостов, и за интеграцию, и за дальнейшую поддержку. В Казахстане такие проекты часто делают с опорой на локально произведенные серверы и сервисную сеть, например у GSE.kz (gse.kz) это может быть поставка серверов серии S200 и системная интеграция под вашу схему виртуализации.