Распространенные проблемы лицензионного несоответствия в облаках Microsoft

Опубликовано: 8 ноября 2018 г.


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

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

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

Не будем делать поспешных выводов и исследовать только общие вопросы, связанные с развертыванием облачных служб Microsoft.


Чтобы понять влияние облака на инфраструктуру, разделим на пункты:
  1. мультиплексирование
  2. гибридное облако/локальные развертывания
  3. совмещение разных планов и тарифов одного и того же сервиса
  4. виртуальные машины в Azure

1. Мультиплексирование
Метод мультиплексирования в информационных технологиях подразумевает объединение нескольких потоков данных (виртуальных каналов) в один.

В Microsoft Product Terms (январь 2018) представлено следующее упоминание: «Применение мультиплексирования или пулинга для сокращения количества прямых подключений к программному обеспечению не уменьшает требуемое количество Лицензий».

Полное определение дано в Product Use Rights в январе 2013 года: «Аппаратное или программное обеспечение, которое используется для создания пулов подключений, перенаправления данных, уменьшения количества устройств или пользователей, напрямую обращающихся к продукту, или уменьшения количества операционных сред (OSE), устройств или пользователей, которыми продукт управляет напрямую (иногда называемое оборудованием или программным обеспечением «мультиплексирования» или «пулинга»), не уменьшает требуемое количество лицензий любого типа».

Таким образом, если системы взаимосвязаны и работают на программном обеспечении Microsoft, и система B извлекает данные из системы A, а к системе B обращаются несколько клиентов, вы, вероятно, мультиплексируете. Это означает, что пользователи, обращающиеся к системе B, также должны иметь лицензию на косвенный доступ к системе A.

Если системы взаимосвязаны и работают на ПО Microsoft, и система B извлекает данные из системы A, а к системе B обращаются несколько клиентов, пользователи, обращающиеся к системе B, также должны иметь лицензию на косвенный доступ к системе A.

Например:

  • Dynamics 365 используется с Power BI
Предположим, компания использует Dynamics 365 (Microsoft CRM и ERP) и Power BI (для создания и совместного использования панелей мониторинга, отчетов и других форм бизнес-аналитики). Данные из Microsoft Dynamics 365 извлекаются в Power BI для создания отчета.

Поскольку для большинства типов клиентского доступа к Dynamics 365 требуется клиентская лицензия (Лицензия подписки SLs), помимо клиентских SLs, необходимых для доступа к Power BI, для доступа к Dynamics 365 потребуются дополнительные SLs.

Легко контролировать такую ситуацию, если есть четкое представления об ИТ-архитектуре. Рекомендуется создавать и обновлять схему ИТ–среды, получая представление о том, какие системы взаимодействуют друг с другом и легче определяя эти типы ситуаций.

Рекомендуется создавать и обновлять схему ИТ–среды для представления о том, какие системы взаимодействуют друг с другом, и понимания ситуаций, когда требуются дополнительные лицензии.
2. Гибридное облако/локальные развертывания
Много прогнозов и предпосылок, что в будущем большинство вычислений будет выполняться в облаке. Пока мы двигаемся в этом направлении, видим некоторые промежуточные этапы. Например, сценарий развертывания в гибридном облаке и локальной среде. Таким образом, компания использует то, чем уже владеет (сокращая затраты), и объединяет это с преимуществами облака.

Управление гибридной средой не вызывает трудностей, но в то же время сопровождается дополнительными («скрытыми») требованиями к лицензированию.

Управление гибридной средой сопровождается дополнительными («скрытыми») требованиями к лицензированию.

Например:

  • Exchange Server Online развернут параллельно с Exchange Server
У компании A гибридная установка Exchange Server Online (как часть Office 365) и Exchange Server (локальная установка) на предприятии. Некоторые почтовые ящики пользователей размещаются в Exchange Online, а некоторые — на локальном сервере Exchange Server. Почта проходит через сервер Exchange Online.

Exchange Server Online использует функцию Exchange Online Protection (EOP — функция, которая фильтрует входящую и исходящую электронную почту для предотвращения вредоносных программ и спама).

Поскольку почта проходит через сервер Exchange Online, сообщения фильтруются с помощью Exchange Online Protection. Таким образом, появляются нелицензированные пользователи, которые используют EOP, если у них нет соответствующей лицензии.

В данном случае пользователи Exchange лицензируются для EOP следующим образом:

  • Лицензии подписки пользователей Exchange Online для пользователей Exchange Server Online;
  • Клиентские лицензии Exchange Server Enterprise с Software Assurance для локального сервера Exchange Server;
При развертывании гибридных сред учитывайте компоненты, включенные в каждый облачный программный продукт, как правило, обладающий дополнительным функционалом. Таким образом, делайте правильный выбор: либо лицензируйте дополнительные функции, чтобы обеспечить одинаковый уровень развертывания как в облаке, так и локально, либо перенастройте среды с правильным разделением.

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

При этом легко выйти из соответствия, если доступ пользователя не управляется корректно.

Практический пример:

  • Azure Active Directory (AD)
Azure AD предоставляет управление доступом к приложениям и защиту учетных данных. Azure AD имеет четыре выпуска лицензий подписки пользователя:
  • Azure AD уровня "Бесплатный"
  • Azure AD Basic
  • Azure AD Premium 1 (Azure AD P1)
  • Azure AD Premium 2 (Azure AD P2)
Предположим, компания A определила две группы пользователей. Первая группа — сотрудники, которым нужен только базовый доступ к электронной почте и достаточно бесплатного или базового плана.

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

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

Чтобы не попасть в такую ситуацию, рекомендуем определять профили пользователей на основе вариантов использования. Профили группируются отдельно, а группы связываются соответствующим планом подписки.

Определяйте профили пользователей на основе вариантов использования. Профили группируются отдельно, а группы связываются соответствующим планом подписки.

Вот некоторые практические руководства:

4. Виртуальные машины в Azure
Размещение виртуальных машин в Azure — облачной платформе Microsoft, предоставляющей возможность разработки и выполнения приложений и хранения данных на серверах, расположенных в распределённых дата-центрах под управлением Windows Server и др.

Очевидны две возможные причины проблем соответствия:

  • Виртуальная машина Azure подключена к локальным системам)

Если система B подключается к виртуальной машинe в Azure, для извлечения данных из базы данных в Azure VM, например, пользователи, подключающиеся к системе B, косвенно подключаются к Azure А. Данный вид мультиплексирования может потребовать дополнительные клиентские лицензии.

  • Клонируемые ВМ импортируются напрямую в Azure)
Виртуальные машины Azure создаются непосредственно в Azure или импортируют клонированную виртуальную машину в Azure, что иногда удобнее и быстрее. Однако если виртуальная машина, импортируемая в Azure, не проверяется на наличие установленного программного обеспечения, это приводит к проблеме лицензионного несоответствия.

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

Проверяйте предустановленное ПО перед непосредственным импортом виртуальной машины в Azure. Если нет запасных лицензий в пуле для покрытия клонированной виртуальной машины, проще создать виртуальную машину с нуля.

Больше информации и практических советов по теме лицензирования облачных сервисов вы можете получить на курсе «Лицензирование продуктов Microsoft»

Если вы хотите научиться управлять лицензионным ПО и получать от этого выгоды, рекомендуем курс «Управление программными активами на предприятии (Software Asset Management – SAM): теоретические и практические аспекты»


Узнать подробнее

Популярное в Блоге