ОПТИМИЗАЦИЯ ЛИЦЕНЗИЙ КЛИЕНТСКОГО ДОСТУПА

Установление правдивой картины по текущей утилизации клиентских лицензий (Client Access License, CAL) клиент-серверного ПО – одна из самых сложных задач для менеджера, управляющего программными активами. Использование лицензий типа "Named" и "Concurrent" трудно отслеживать, так как «экземпляр» подобного рода ПО – это факт взаимодействия между клиентским приложением и сервером.
На примере реального продукта со сложной схемой лицензирования давайте попробуем разобраться, как обнаружить и правильно идентифицировать экземпляры клиентских лицензий (то есть составить реальную картину утилизации существующих лицензий), а также рассмотрим возникающие сложности и ограничения.

ПРИМЕР СТРУКТУРЫ ЛИЦЕНЗИРОВАНИЯ ПРОДУКТА

Для наглядности я выбрал конкретный программный продукт, HP Asset Manager. Несмотря на то, что это средство автоматизации для управления ИТ-активами, HP Asset Manager сам имеет достаточно сложную схему лицензирования и обладает всеми признаками «проблемного» (с точки зрения контроля лицензий) ПО. Это нам как раз и нужно для понимания сути проблемы и путей решения.

 

Рисунок 1. Схема лицензирования HP Asset Manager
Схема лицензирования HP Asset Manager


Итак, что мы имеем:

  • Серверная лицензия, необходима для функционирования сервера HP Asset Manager;
  • Блок лицензий для пользователей. Для выполнения основных операций в системе используется лицензия для управления портфелем активов, но для расширения функциональности потребуются специализированные лицензии: например, если требуется работа с бюджетами, то придется дополнительно приобрести лицензии на управление финансами. Обратите внимание, что использование специализированных лицензий невозможно без основных пользовательских лицензий управления портфелем;
  • Все лицензии для пользователей разделяются на два типа, именные и конкурентные;
  • Возможно использование двух типов клиентов, «толстого» и «тонкого».

 

СИТУАЦИИ НЕОПТИМАЛЬНОГО ИСПОЛЬЗОВАНИЯ ЛИЦЕНЗИЙ

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

В нашем же случае HP Asset Manager не допустит использования большего количества лицензий, чем то, которое было приобретено. И поэтому сценарий недолицензирования для HP Asset Manager является неактуальным.

Избыток лицензий (перелицензирование)) – лицензий приобретено больше, чем используется. В данном случае вы соблюдаете требование «лицензионной чистоты», но расходуете денег на лицензии больше, чем необходимо. Учитывая то, что клиентские лицензии могут стоить весьма недешево (например, специализированная конкурентная лицензия для управления финансами «AM De-synced Financial Management TB657AAE» стоит порядка 6000$), вы получаете возможность значительной экономии денежных средств.

Именно эта задача – снизить количество неиспользуемых лицензий, и стоит перед нами в случае с HP Asset Manager. Для этого необходимо понять, насколько оптимально используются приобретенные лицензии.

ЭКЗЕМПЛЯРЫ ПО

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

В отличие от приложений, для которых выполняется установка ПО (например, установленный пакет Microsoft Office на рабочей станции), экземпляром ПО для конкурентных и именных лицензий является факт коммуникации между клиентом и сервером. И как таковой «установки» специфического клиентского приложения может и не быть – например, будет использоваться интернет-браузер:

 

Рисунок 2. Одна сессия между клиентом и сервером порождает один экземпляр ПО
Одна сессия между клиентом и сервером порождает один экземпляр ПО


Более того, в некоторых случаях, одна сессия между клиентом и сервером может порождать несколько экземпляров ПО:

 

Рисунок 3. Одна сессия между клиентом и сервером порождает несколько экземпляров ПО
Одна сессия между клиентом и сервером порождает несколько экземпляров ПО


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

ОБНАРУЖЕНИЕ И ИДЕНТИФИКАЦИЯ ЭКЗЕМПЛЯРОВ ПО НА КЛИЕНТАХ

Как уже упоминалось, возможно использование двух типов клиентов, «толстого» и «тонкого».

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

 

Рисунок 4. Обнаружение и идентификация «толстого» клиента
Обнаружение и идентификация «толстого» клиента


На рисунке 4 мы видим, что средство автоматической инвентаризации обнаружило на рабочей станции установленный «толстый» клиент HP Asset Manager, однако экземпляры ПО для пользовательских лицензий не обнаружены.

Факт наличия клиентского ПО не скажет нам о том, что:

  • В данный момент клиент подключен к серверу и использует определенную лицензию:
  • На одной рабочей станции может поочередно (используя различные профили) работать несколько человек;
  • Один человек может запускать клиентское приложение на разных рабочих станциях.
 

Рисунок 5. Отсутствие коммуникации между клиентом и сервером при активном клиентском приложении
Отсутствие коммуникации между клиентом и сервером при активном клиентском приложении

Клиент HP Asset Manager запущен, однако нет подключения к серверу. Клиентская лицензия не используется.

 

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

Таким образом, для обнаружения и идентификации экземпляров ПО на клиенте придется решить следующие задачи:

  1. Отслеживать наличие трафика между клиентом и сервером. Это позволит понять, что в данный момент времени действительно существует определенный экземпляр ПО (что лицензия действительно «используется», а не «простаивает»). Такая возможность обычно обеспечивается мониторингом определенных портов, которые использует приложение;
  2. Инспектировать трафик между клиентом и сервером, чтобы точно идентифицировать обнаруженные экземпляры ПО (и в дальнейшем понять, какие именно лицензии используются). Например, если сотрудник играет роль финансового менеджера, то в случае с HP АМ во время одной сессии он будет порождать два экземпляра ПО, и соответственно использовать две лицензии: управление портфелем и управление финансами. Если все коммуникации между клиентом и сервером шифруются, то такая задача может быть вообще нереализуема;
  3. Отслеживать учетные данные пользователя, от имени которого был произведен вход в систему. Для конкурентных лицензий это необязательное условие, в отличие от именных. Так как именные лицензии зарезервированы за определенным сотрудником, нам необходимо понимать, кто именно порождает в определенный момент времени экземпляр ПО.

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

ОБНАРУЖЕНИЕ И ИДЕНТИФИКАЦИЯ ЭКЗЕМПЛЯРОВ ПО НА СЕРВЕРЕ

В этом случае задача по обнаружению и идентификации экземпляров ПО значительно упрощается: вместо множества точек приложения усилий (клиентов) можно сосредоточится на одном компоненте – сервере. И здесь мы получаем прекрасную возможность использовать особенность серверной части приложения хранить данные о текущих сессиях, активных пользователях и используемых лицензиях. Как правило, такая информация хранится в журналах и/или в таблицах базы данных (если приложение использует базу данных) с названиями вроде «sessions», «users», «license_info» и т.д.

 

Рисунок 6. Информация о текущих сессиях пользователей HP Asset Manager в базе данных
Рисунок 6. Информация о текущих сессиях пользователей HP Asset Manager в базе данных


Таким образом, теоретически мы можем точно идентифицировать используемые лицензии ПО.

На практике же существуют некоторые проблемы:

  • Значительная часть инструментов автоматической инвентаризации с конфигурацией «из коробки» (out-of-the-box) не сможет обнаружить и корректно идентифицировать подобные экземпляры ПО:

    Рисунок 7. Обнаружение ПО HP Asset Manager с помощью системы инвентаризацииРисунок 7. Обнаружение ПО HP Asset Manager с помощью системы инвентаризации

    Средство автоматической инвентаризации обнаружило установленное серверное ПО HP Asset Manager, однако экземпляры ПО для пользовательских лицензий не обнаружены.


    В этом случае может потребоваться дополнительная настройка агентов или механизма сканирования без использования агентов. Некоторые производители средств автодискаверинга предлагают использование специализированных пакетов-расширений для обнаружения экземпляров конкурентных и именных лицензий. Но, как правило, такие пакеты предназначены для отдельной продуктовой линейки конкретного вендора: Microsoft, Oracle и т.д. Какого-то универсального решения для всех продуктов не существует;
  • Приложения используют различные форматы хранения данных в журналах, и для «разбора» такой информации не существует универсального решения. Придется для каждого приложения дополнительно настраивать систему автодискаверинга, либо использовать специализированные средства сбора информации. К сожалению, нередки случаи, когда в журнал записывается слишком мало данных, которых недостаточно для оценки утилизации лицензий;
  • Информация о логинах, лицензиях и пользователях в зависимости приложения может быть распределена по разным таблицам базы данных. Эти таблицы еще нужно найти (а это бывает не так просто сделать) и консолидировать необходимую информацию. Обычно эта задача решается за счет создания представлений. Но нужно понимать, что разные приложения имеют отличающиеся структуры хранения данных, поэтому универсальное представление, которое подходит для всех приложений даже для определенного типа базы данных (например, SQL) создать практически невозможно;
  • Нередки случаи, когда интересующая нас информация зашифрована. В этом случае можно попытаться использовать графический интерфейс приложения для поиска нужных данных (к сожалению, в этом случае придется использовать ручной труд администратора системы), либо использовать принадлежность пользователя к определенным функциональным ролям. Тогда в зависимости от роли мы сможем сделать вывод, какая именно лицензия утилизируется. Но для этого придется поддерживать в актуальном состоянии таблицу взаимосвязей ролей и лицензий, что является дополнительной ручной работой:

    Рисунок 8. Информация об утилизации лицензий на основе принадлежности пользователя к группамРисунок 8.  Информация об утилизации лицензий на основе принадлежности пользователя к группам

    Сотрудник с ролью «Специалист по закупкам ИТ-активов» использует 2 лицензии во время одного сеанса: конкурентную лицензию по управлению портфелем активов (об этом говорит значение «Непостоянный» в столбце «Тип доступа») и конкурентную лицензию управления закупками.

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

РЕЗУЛЬТАТЫ

Используя необходимые представления базы данных приложения и дополнительную настройку средств автоматической инвентаризации, для HP Asset Manager в автоматическом режиме удалось получить информацию об утилизации клиентских лицензий управления портфелем активов:

 

Рисунок 9. Контроль утилизации лицензий HP Asset Manager в автоматическом режиме
Рисунок 9.  Контроль утилизации лицензий HP Asset Manager в автоматическом режиме


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

Несмотря на наличие ручных процедур, мы достигли цели – получили достоверную картину об утилизации клиентских лицензий.

ВЫВОДЫ

  1. Для обнаружения и идентификации экземпляров ПО желательно сосредоточиться на серверных компонентах клиент-серверных приложений, использование клиентской части – обычно неэффективно;
  2. По возможности использовать базовое средство автоматической инвентаризации с хорошим функционалом в части обнаружения данных об утилизации лицензий клиентского доступа. Чем больше приложений, для которых есть механизмы контроля использования CAL в пакете «из коробки» у системы автодискаверинга – тем лучше;
  3. Желательно использовать специализированные средства от производителей ПО в дополнение к базовому средству автоматической инвентаризации. Это может помочь, если система автодискаверинга не умеет работать с некоторыми приложениями определенных вендоров. Примерами таких инструментов могут служить Microsoft Assessment and Planning Toolkit (MAP Toolkit), Linux User Management (LUM), серверы лицензирования (например, Sentinel RMS) и т.д.
  4. В некоторых случаях придется применять процедуры ручного сбора данных по утилизации лицензий.
 

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

Михаил Тобурдановский, ITAM2.RU Project, управляющий партнер

Яндекс.Метрика