Лицензирование, часть 7. Новое в лицензировании — свободное перемещение экземпляров ПО

Месяц назад я анонсировал вебкаст про лицензирование и пообещал, что в нём будут объявлены некие новые условия лицензирования в виртуальных средах. К сожалению, ничего нового в том вебкасте сказано не было — то ли было решено отложить публичные объявления, то ли просто у докладчиков что-то «не срослось». Но вот сегодня, наконец, об этих изменениях было объявлено официально — и я спешу поделиться с вами.

Краткий обзор

Изменения вступают в силу первого сентября 2008 года и относятся как к продуктам, которые доступны сейчас, так и к новым версиям. Основное нововедение — теперь лицензии можно учитывать (и привязывать) не по каждому серверу в отдельности, а по фермам серверов (Server Farm). Очевидно, что это даёт огромное снижение расходов при переносе установленных продуктов между серверами и даже центрами обработки данных (ЦОД, они же Datacenters). Это касается любых типов переноса — как традиционного (удалили на одном сервере, установили на другом), так и более технологичных, например, миграции виртуальных машин.

Напомню, что раньше все лицензии необходимо было привязывать (assign) к конкретным серверам, на которых будет использоваться то или иное ПО. Причём существовало ограничение на перенос (reassignment) лицензий — это можно было делать не чаще, чем раз в 90 дней (за исключением ситуаций, когда перенос вызван отказом оборудования). Таким образом, если вам необходимо перемещать установленный продукт чаще — приходилось приобретать несколько лицензий. По одной для каждого сервера, на котором может выполняться приложение в какой-либо момент времени. Новые правила снимают это ограничение. Разумеется, при следующих условиях:

  • все серверы расположены в пределах одной фермы — к которой и привязывается лицензия;
  • ПО никогда не выполняется одновременно на большем количестве серверов, чем охватывается количеством приобретённых лицензий.

Область действия

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

  • серверных операционных систем (Windows Server);
  • лицензий клиентского доступа (Client Access License, CAL);
  • лицензий на управление (Management Licenses, ML);
  • любых лицензий, приобретённых в розницу (Retail) или в комплекте с оборудованием (OEM).

Иными словами, изменения касаются только лицензий, приобретаемых по программам корпоративного лицензирования (Volume License), а точнее:

  • Open License (включая Academic и Government),
  • Open Value,
  • Open Value Subscription,
  • Enterprise Agreement,
  • Enterprise Agreement Subscription.

Определение фермы серверов (Server Farm)

Признаться, оно меня несколько озадачило — раньше я понимал под фермой нечто совсем другое, намного меньших масштабов. Итак, с точки зрения нашей сегодняшней темы, фермой серверов являются один или два ЦОД, при условии, что:

  • оба расположены на территории стран — участниц следующих международных объединений (Россия пока не входит ни в одно из них):
    • Европейский союз (European Union, EU). Список членов ЕС находится на официальном сайте,
    • Европейская ассоциация свободной торговли (European Free Trade Association, EFTA). Список членов ЕАСТ находится на официальном сайте;
  • и/или находятся друг от друга на расстоянии, не превышающем четыре часовых пояса. При этом руководствоваться следует Универсальным координированным временем (Universal Coordinated Time, UTC) без учёта перехода на летнее время (Daylight Saving Time, DST). Карту мира с указанием часовых поясов можно посомотреть хотя бы на сайте ЦРУ (PDF, 833 Kb).

Последнее ограничение также звучит достаточно непривычно, поэтому приведу несколько примеров. Все эти варианты являются подходящими — так как территория покрывается не более, чем четырьмя часовыми поясами:

  • США, исключая Аляску;
  • Европа, Африка и Израиль;
  • Китай, Австралия и Корея.

А вот разместить один ЦОД в Москве, а другой в Хабаровске уже не получится. Вернее, эти ЦОД не могут считаться членами одной фермы. Зато вполне подойдёт, например, вариант с размещением ЦОД в Калининграде и Новосибирске. Или в Африке и в Антарктиде.

Каждый ЦОД может являться членом только одной фермы. Вы можете переопределить ЦОД к другой ферме — но не чаще, чем раз в 90 дней.

Полный текст объявления на английском языке опубликован на странице Volume Licensing Briefs — ищите документ под названием «Application Server License Mobility».

Лицензирование продуктов по количеству процессоров (per Processor)

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

При этом, как и раньше, учитываются только физические процессоры — то есть сокеты, а не отдельные ядра или потоки Hyper-Threading. Если продукт выполняется в виртуальной среде операционной системы (Operating System Environment, OSE), которой выделено меньше виртуальных процессоров, чем имеется физических на сервере виртуальных машин, то необходимо только то количество лицензий, которое соответствует количеству виртуальных процессоров — без учёта физических.

Продукты, которые используют схему лицензирования по процессорам и подпают под изменения в правилах лицензирования

  • BizTalk Server 2006 R2 Enterprise Edition;
  • Commerce Server 2007 Enterprise Edition;
  • Internet Security and Acceleration (ISA) Server 2006 Enterprise Edition;
  • SQL Server 2008 Enterprise.

Обратите внимание, что редакции Standard этих продуктов также лицензируются по процессорам. Однако, в отношении этих продуктов никаких изменений не происходит, и правила лицензирования остаются прежними.

Примеры

Допустим, в вашей инфраструктуре используются четырёхпроцессорные серверы. Каждый процессор имеет по два ядра, причём включена функция Hyper-Threading. В сумме получается 4×2×2 = 16 логических процессоров, которые доступны ПО виртуализации.

Пример 1. На физичесом сервере запущена одна виртуальная машина, которой доступны два виртуальных процессора. В виртуальной машине установлен BizTalk Server 2006 R2 Enterprise Edition и использует оба виртуальных процессора. Используя старую схему лицензирования нам потребуется приобрести лицензии для BizTalk Server 2006 R2 Enterprise Edition по количеству процессоров (сокетов) физического сервера — то есть, четыре штуки.

С учётом изменений в схеме лицензирования нам потребуется приобрести столько лицензий для BizTalk Server 2006 R2 Enterprise Edition, сколько в действительности используется продуктом. Так как наша виртуальная машина использует два логических процессора, то максимальное количество физических процессоров, которое она может использовать одновременно — тоже два (в случае, когда она использует по одному потоку одного ядра каждого физического процессора). Таким образом, нам требуется только две лицензии для BizTalk Server 2006 R2 Enterprise Edition.

Пример 2. Добавим ещё две таких же виртуальных машины, в которых запущен BizTalk Server 2006 R2 Enterprise Edition. Теперь общее количество виртуальных процессоров, которые использует BizTalk, составляет 2×3 = 6. При использовании старой схемы лицензирования, нам потребуется по одной лицензии для каждого процессора — из тех, что доступны внутри виртуальных машин (то есть, внутри среды, OSE). Иными словами, придётся приобрести шесть лицензий для BizTalk Server 2006 R2 Enterprise Edition.

Используя новую схему лицензирования, нам нужно подсчитать максимальное количество физических процессоров (сокетов), которые могут быть задействованы в один момент времени. В данном случае это четыре — так как больше в нашем сервере просто нет. Поэтому и по новой схеме лицензирования нам тоже требуется четыре лицензии на BizTalk Server 2006 R2 Enterprise Edition.

Пример 3. Возьмём ситуацию из предыдущего примера, только в качестве лицензируемого продукта используем SQL Server Enterprise вместо BizTalk Server 2006 R2 Enterprise Edition. У этого продукта есть уникальное свойство — по старым правилам лицензируется только то количество процессоров (сокетов), которое присутствует в физическом сервере. В нашем случае это четыре — следовательно, здесь нам потребуется четыре лицензии для SQL Server Enterprise (при условии, что мы избрали способ лицензирования именно по числу процессоров, а не по количеству серверов и числу подключений. Об этом способе речь пойдёт ниже).

В данном случае, новая схема лицензирования ничего особенного не меняет. Мы точно так же подсчитаем количество процессоров (сокетов) в физическом сервере и приобретём четыре лицензии для SQL Server Enterprise. Аналогично ситуации с BizTalk Server 2006 R2 Enterprise Edition в предыдущем примере.

Пример 4. Вернёмся к примеру 2, но внесём ещё одно дополнителное условие. Допустим, что вы используете ПО виртуализации, которое позволяет жёстко ограничить — на каких логических процессорах будет выполняться та или иная ВМ. Используя эту возможность, вы указали, что все три ВМ будут выполняться на первых восьми логических процессорах, что соответствует двум физическим процессорам (сокетам) в вашем сервере.

При использовании старой схемы лицензирования, ничего не изменится — потому что в ней нет оговорок для тех случаев, когда лицензируемое ПО использует только некоторые процессоры. То есть вам по-прежнему потребуется шесть лицензий для BizTalk Server 2006 R2 Enterprise Edition. Если мы станем говорить о SQL Server Enterprise, то здесь также ничего не изменится по сравнению с примером 3. Нам потребуется четыре лицензии — по числу процессоров (сокетов) в физическом сервере.

Однако изменения в схеме лицензирования чётко указывают, что количество необходимых лицензий ограничено только действительно используемыми физическими процессорами (сокетами). Таким образом, нам требуется всего две лицензии для BizTalk Server 2006 R2 Enterprise Edition. Аналогично и со SQL Server Enterprise — в этом случае нам также понадобится две лицензии.

Пример 5. Мы добавляем в ферму ещё один такой же сервер и объединяем два сервера в кластер. Теперь три наших двухпроцессорных виртуальных машины, на которых установлен BizTalk Server 2006 R2 Enterprise Edition, могут выполняться на обоих физических серверах — как вместе, так и по отдельности. Используя старую схему лицензирования, нам придётся учесть все ситуации: и когда все три машины работают на первом сервере, и когда все они перемещаются на второй. В каждом случае нам потребуется по шесть лицензий для BizTalk Server 2006 R2 Enterprise Edition, а в сумме — двеннадцать.

Принимая во внимания изменения в схеме лицензирования, мы будем считать совсем по-другому. Даже в худшей ситуации, когда каждый виртуальный процессор выполняется на одном физическом, мы никогда не задействуем одновременно больше, чем 2×3 = 6 процессоров. А значит — именно столько лицензий для BizTalk Server 2006 R2 Enterprise Edition нам необходимо приобрести.

Пример 6. Заменим в предыдущем примере BizTalk Server 2006 R2 Enterprise Edition на SQL Server Enterprise. Тогда согласно старой схеме лицензирования вам окажется достаточно просто подсчитать количество процессоров (сокетов) во всех физических серверах — а это 4×2 = 8. Именно столько вам потребуется лицензий для SQL Server Enterprise. Согласно новой схеме всё получается так же, как в предыдущем примере. Считаем логические процессоры, а не физические — и получаем, что нам необходимо шесть процессорных лицензий.

Как видим, наибольшая выгода от изменений в схеме лицензирования заметна на примере BizTalk Server 2006 R2 Enterprise Edition. Аналогично будет и с другими продуктами этого типа — за исключением SQL Server Enterprise, где правила и раньше были достаточно либеральными. Однако и здесь наблюдается вполне заметная экономия. Причём эта выгода, то есть разница между количеством лицензий, необходимых согласно старой и новой схем лицензирования, будет здорово увеличиваться — по мере того, как мы будем добавлять физические серверы в кластер, оставляя без изменений количество виртуальных машин, на которых выполняется тот или иной продукт.

Лицензирование продуктов по количеству серверов и числу подключений (per Server + CAL)

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

И здесь для SQL Server Enterprise предусмотрены более выгодные условия, чем для остальных продуктов. Имея одну лицензию на сервер, вы можете запускать любое количество экземпляров продукта в пределах одного физического сервера. Имея две лицензии — в пределах двух серверов, и так далее. Причём с учётом изменений в схеме лицензирования, речь теперь идёт о любых серверах в пределах вашей фермы, а не каких-то конкретных. Важно лишь то, чтобы в каждый момент времени общее количество физических серверов, на которых выполняются экземпляры SQL Server Enterprise, не превышало количество серверных лицензий для этого продукта, привязанных к вашей ферме.

Продукты, которые используют схему лицензирования по количеству серверов и числу подключений и подпадают под изменения в правилах лицензирования

  • Connected Services Framework 3.0 — Server, SBE Server Billing, SBE Server Order Handling;
  • Custurmer Care Framework 2008;
  • Duet For Microsoft Office and SAP;
  • Dynamics CRM 4.0 — Enterprise Server, Professional Server;
  • Exchange Server 2007 — Enterprise Edition, Standard Edition;
  • Forefront Client Security Management Console, Forefront Client Security Management console with SQL Server Technology;
  • Forefront Server Security Management Console;
  • Identity Lifecycle Manager 2007;
  • Office Communications Server 2007 — Standard Edition, Enterprise Edition;
  • Office Forms Server 2007; Office Forms Server 2007 for Internet Sites;
  • Office Groove Server 2007;
  • Office PerformancePoint Server 2007;
  • Office Project Portfolio Server 2007;
  • Office Project Server 2007;
  • Offce SharePoint Server 2007; Office SharePoint Server 2007 for Internet Sites;
  • Search Server 2008;
  • SQL Server 2008 Enterprise;
  • System Center Configuration Manager 2007, System Center Configuration Manager 2007 with SQL Server Technology;
  • System Center Data Protection Manager 2007;
  • System Center Essentials 2007, System Center Essentials 2007 with SQL Server Technology;
  • System Center Mobile Device Manager 2008, System Center Mobile Device Manager 2008 with SQL Server Technology;
  • System Center Operations Manager 2007; System Center Operations Manager 2007 with SQL Server Technology;
  • System Center Virtual Machine Manager 2007;
  • Visual Studio Team System 2008 Team Foundation Server with SQL Server Technology;
  • Visual Studio Team System 2008 Test Load Agent.

Обратите внимание — в отличие от предыдущего списка (который включает продукты, лицензируемые по количеству процессоров) здесь большинство продуктов представлено как в редакциях Enterprise, так и Standard. Напоминаю также, что хотя продукты этого типа лицензируются по количеству серверов и числу клиентских подключений, изменения в схеме лицензирования касаются только первой части этой формулы. То есть условия лицензирования клиентских подключений остаются прежними — это касается как Лицензий клиентского доступа (Client Access License, CAL), так и Лицензий на управление (Management License, ML).

Примеры

Пример 1. Вы используете три виртуальных машины. В каждой из них установлен Mocrosoft Office SharePoint Server (MOSS). Эти виртуальные машины выполняются на кластере, который состоит из восьми физических узлов. Согласно старым правилам лицензирования, вам необходимо приобрести лицензии для каждого физического сервера в кластере. Причём для каждого сервера вам требуется приобрести столько лицензий, сколько ВМ с MOSS могут одновременно выполняться на этом сервере. В описанной конфигурации все три ВМ могут одновремено выполняться на любом узле кластера — таким образом, вам понадобится 3×8 = 24 лицензии!

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

Пример 2. Возьмём ситуацию из предыдущего примера, но будем использовать другой продукт — SQL Server Enterprise вместо MOSS. Используя старую схему лицензирования, нам потребуется лицензия для каждого физического сервера, на котором хотя бы иногда может выполняться SQL Server Enterprise. Очевидно, что это все серверы кластера — то есть, восемь штук. И именно столько серверных лицензий для SQL Server Enterprise вам потребуется в этом случае.

Согласно новым правилам лицензирования, вам требуется подсчитать количество физических серверов, на которых может выполяться SQL Server Enterprise одновременно. Поскольку у вас всего три виртуальных машины с этим продуктом, максимальное количество узлов кластера, на которых они могут выполняться одновременно — тоже три. А значит, вам потребуется всего три серверных лицензии для SQL Server Enterprise.

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

Пример 3. Изменим соотношение между количетсвом запущенных экземпляров SQL Server Enterprise и числом физических серверов в кластере. Возьмём ситуацию, где пять виртуальных машин с установленным SQL Server Enterise выполняются на трёх физических серверах. Используя старую схему лицензирования, мы считаем общее число физических серверов в кластере и получаем, что нам требуется приобрести три серверных лицензии для SQL Server Enterprise.

Учитывая изменения в схеме лицензирования, мы подсчитываем максимальное количество физических серверов, на которых могут выполняться все экземпляры SQL Server Enterprise одновременно. Однако, в данном случае получается, что это число равно общему числу физических серверов в кластере — то есть, снова трём. Поэтому этот пример плохо иллюстрирует разницу между старой и новой схемами лицензирования.

Однако здесь хорошо видно отличие лицензирования SQL Server Enterprise от других продуктов, которые лицензируются по подобной схеме — в том числе, и SQL Server Standard. Ведь в других случаях лицензирования по количеству серверов, согласно новым правилам, нам потребуется приобретать количество лицензий по числу одновременно запущенных экземплыров продукта. В данном случае это число равно пяти. Сравните это число с количеством лицензий для SQL Server Enterprise, которые учитываются по числу задействованных физических серверов.

Лицензии для использования продукта внешними пользователями (External Connector)

Что это такое 

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

Иногда возникают ситуации, когда вам требуется предоставить доступ к серверам, принадлежащим вашей фирме, лицам, которые не являются её сотрудниками и не связаны с ней работой по контракту. В этом случае вы можете лицензировать такие подключения на обычных условиях — с помощью CAL. Но если таких людей очень много, или их сложно учитывать, то такая схема может оказаться весьма накладной. В этом случае вы можете приобрести лицензию особого типа. Такая лицензия называется External Connector, EC. Она привязывается к серверу и даёт право подключаться к этому серверу неограниченному количеству внешних пользователей.

Надо понимать, что это не отменяет необходимости отдельно лицензировать доступ тех пользователей, которые всё-таки являются сотрудниками вашей огранизации. Также наличие EC не отменяет необходимости лицензировать сам сервер. Иными словами, в схеме лицензирования «по количеству серверов и числу подключений», EC служит альтернативой только второй половине формулы, то есть покупке CAL. Лицензию для установки продукта на сервер всё-таки требуется приобрести отдельно.

Для использования лицензий типа External Connector существует ещё одно ограничение. Требуется, чтобы доступ осуществлялся в интересах владельца сервера, а не подключающихся лиц. Примером законного использования EC может являться организация доступа для сотрудников фирмы-контрагента. Пример противоположенной ситуации — предоставление услуг веб-хостинга. В этом случае заинтересованной стороной является не провайдер услуги, а его клиент. Поэтому такой сценарий не является областью применения лицензий типа EC. Для таких случаев предназначен совсем другая схема лицензирования. Она называется Service Provide License Agreement (SPLA) и предусматривает размер оплаты пропорционально объёму предоставляемых и оплачиваемых услуг. Впрочем, эта схема выходит за пределы темы данной заметки, так как последние изменения в правилах лицензирования никак её не затрагивают.

Изменения схемы лицензирования 

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

Согласно изменениям в схеме лицензирования, теперь вам не требуется жёстко привязывать лицензии типа EC к физическим серверам. Вы можете привязать их ко всей ферме в целом. При этом требуется, чтобы общее количество лицензий типа EC, привязанных к ферме, не превышало количество физических серверов, на которых в один момент времени выполняются экземпляры лицензированного продукта, к которым имеют доступ внешние пользователи, не имеющие CAL. Сам продукт по-прежнему можно запускать в неограниченном количестве экземпляров. Учитывается лишь количество физических серверов, на которых одновременно выполняются все эти экземпляры.

Пример

Три сервера виртуализации работают в кластере. На нём запущено пять виртуальных машин с MOSS. Два из них обслуживают сотрудников организации, для которых приобретены CAL-ы. Третья машина обслуживает сотрудников фирмы-поставщика. Это несколько заранее определённых людей, в обязанности которых входит вести документооборот с вашей фирмой. Поэтому для этих пользователей также приобретены CAL-ы. Оставшиеся два сервера MOSS обслуживают многочисленных сотрудников фирм-заказчиков. Этих пользователей сложно учитывать, потому что люди часто меняются, и каждому из них доступ к вашим серверам требуется лишь изредка. Поэтому такие подключения целесообразно лицензировать с помощью External Connector.

При соблюдении прежних правил лицензирования, вам потребуется:

  • 3×5 = 15 серверных лицензий для MOSS (так как каждый из пяти экземпляров одновременно может выполняться на любом из трёх физических серверов в кластере. Лицензированию на одинаковых условиях подлежат все экземпляры вне зависимости от типа лицензирования клиентских подключений);
  • Необходимое количество MOSS CAL для пользователей — сотрудников вашей компании (целесообразно рассмотреть лицензирование в рамках Enterprise CAL);
  • Необходимое количество MOSS CAL для пользователей — сотрудников организации-подрядчика (приобретены отдельно);
  • Три MOSS External Connector для пользователей — сотрудников организаций-заказчиков (по числу физических серверов в кластере — так как экземпляры MOSS для внешних пользователей могут выполняться на любых из них).

Учитывая изменения в схеме лицензирования, лицензий потребуется меньше:

  • Пять серверных лицензий для MOSS (по числу экземпляров запускаемого ПО вне зависимости от того, на каких серверах они будут выполняться);
  • Необходимое количество CAL для пользователей — как внутренних, так и организации-подрядчика (распределение CAL-ов никак не затрагивается обсуждаемыми сегодня изменениями в схемах лицензирования);
  • Два MOSS External Connector для пользователей — сотрудников организаций-заказчиков (по числу физических серверов, на которых одновременно могут выполняться оба экземпляра MOSS, лицензируемых для внешних пользователей).