Лицензирование Oracle Database: данные для расчета Processor и NUP

Задача расчета: какие данные нужны и зачем

Лицензирование Oracle Database почти всегда упирается в два вопроса: сколько лицензий нужно и по какой модели считать - Processor или Named User Plus (NUP). Ошибки обычно возникают не в формуле, а в исходных данных: неполные сведения о железе, виртуализации и о том, где именно стоит Oracle.

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

Oracle редко живет на одном «сервере с базой». Чаще это набор окружений: физические хосты, виртуальные кластеры, тест и прод, узлы отказоустойчивости, иногда отдельная DR-площадка. Дополнительно влияет виртуализация: где-то можно ограничиться выделенными ресурсами, а где-то приходится учитывать весь кластер.

Удобно разделять информацию на два слоя:

• Исходные данные: где установлено ПО Oracle, характеристики CPU (модель, сокеты, ядра), тип виртуализации и границы кластера, принадлежность к окружению (prod, test, dev, DR), доступ пользователей и интеграций.
• Результат расчета: количество Processor лицензий с учетом Core Factor, количество NUP (с проверкой минимальных порогов), список узлов и окружений, которые попали в лицензирование.

Если на старте у вас есть только «4 сервера и примерно 200 пользователей», корректного расчета не получится. Нужна конкретика: на каких хостах реально запускается Oracle, сколько там ядер и как устроена виртуализация. Тогда расчет становится повторяемым и проверяемым.

Коротко о моделях: Processor и Named User Plus

В Oracle есть две базовые модели для Oracle Database: Processor и Named User Plus (NUP). От выбора зависит, какие данные собирать и как их трактовать. Важно, чтобы цифры можно было подтвердить документами и выгрузками, а не «примерными оценками».

Processor: лицензия «по мощности»

Processor лицензия считается по количеству процессоров и ядер, с учетом коэффициентов (Core Factor) для конкретной архитектуры CPU. Чем больше вычислительных ресурсов выделено под Oracle, тем больше лицензий нужно, даже если пользователей немного.

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

Named User Plus: лицензия «по людям/устройствам»

NUP привязывается к числу пользователей (или устройств), которые имеют право использовать базу напрямую или косвенно. Это бывает выгодно для закрытых систем: небольшой штат, ограниченный доступ, понятные роли.

Частая причина расхождений - минимумы NUP на процессор. Даже если у вас 10 пользователей, по правилам может получиться больше из-за мощности сервера. Поэтому NUP почти всегда требует параллельной проверки: сколько минимумов выходит «от железа».

Чтобы корректно сравнить Processor и NUP, заранее подготовьте:

• инвентаризацию установок Oracle (какие серверы, где, какие инстансы);
• данные по CPU и конфигурации (с привязкой к виртуализации);
• информацию об окружениях (prod, test, dev, DR) и режиме их работы;
• сведения о пользователях и способах доступа (приложения, интеграции, сервисные учетные записи);
• подтверждающие материалы: отчеты инвентаризации, выгрузки из гипервизора, описания архитектуры.

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

Шаг 1: собрать список систем и точек установки

Первый риск - вы считаете не то окружение. Поэтому начните не с ядер и коэффициентов, а со списка мест, где Oracle реально установлен или может оказаться (включая временные установки администраторов).

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

Дальше отметьте, какие компоненты Oracle используются. Важно различать редакции (EE или SE) и отдельно фиксировать опции и пакеты, которые включались хотя бы на время (например, «для теста»). Даже кратковременное включение может повлиять на расчет.

Параллельно разметьте среды: prod, test, dev, stage, а также DR. Цель простая: чтобы одна и та же база не попала в таблицу дважды под разными названиями, и чтобы DR не «спрятался» как обычный тестовый стенд.

Назначьте владельцев данных. Без ответственных людей инвентаризация быстро превращается в список предположений. Обычно достаточно:

• владелец приложения или сервиса;
• администратор ОС или платформы виртуализации;
• DBA или владелец БД;
• владелец инфраструктуры (кластер, СХД, площадка).

Выберите единый формат таблицы и не меняйте его по ходу сбора. Минимальный набор колонок:

• система (сервер или ВМ), площадка, среда;
• роль (DB, app, standby, DR);
• продукт и редакция Oracle;
• список опций и пакетов (как факт использования);
• точка установки (host, VM, cluster), владелец и контакт.

Пример: «DB-PROD-01» как ВМ в кластере vSphere, среда prod, Oracle Database EE, включалась опция Diagnostic Pack, владелец - команда ERP. Такого уровня детализации достаточно, чтобы переходить к сбору данных по CPU.

Шаг 2: корректно снять данные по процессорам и ядрам

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

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

Hyper-Threading (или SMT) отмечайте отдельно. Он увеличивает число потоков, но не добавляет физических ядер. Поэтому выводы ОС про «логические процессоры» часто вводят в заблуждение: 16 ядер с включенным HT выглядят как 32, но для Processor обычно берут физические ядра, а не потоки.

Уточните тип платформы: обычный rack-сервер, blade, HCI-узел или специализированная система. Это помогает не перепутать границу физического хоста с границей кластера или шасси.

Лучше, когда есть минимум два независимых подтверждения:

• данные из BIOS/UEFI (модель CPU, сокеты, ядра);
• инвентарный отчет (CMDB, учетные системы, акты);
• спецификация поставки или паспорт оборудования;
• серийный номер и модель сервера.

Отдельно фиксируйте единицы измерения: физические ядра, логические потоки, vCPU. В ВМ может быть 8 vCPU, но на хосте - 2 сокета по 12 ядер. Для Processor расчет начинается от физики хоста, а vCPU пригодятся при описании виртуализации и границ учета.

Шаг 3: коэффициенты Core Factor и привязка к CPU

Core Factor - коэффициент, который Oracle применяет в модели Processor, чтобы перевести количество физических ядер в количество Processor лицензий. Он используется только для тех платформ и моделей CPU, для которых значение задано в Oracle Core Factor Table. Если коэффициента нет (или для вашей платформы действует отдельное правило), расчет будет другим. Поэтому сразу определите, какой документ вы используете как источник.

Ключевой момент - точная модель процессора. Одних данных «2 сокета и 16 ядер» недостаточно: у разных семейств CPU может быть разный Core Factor. В инвентаризации фиксируйте минимум: производитель CPU, точная модель (как в выводе ОС или BIOS), количество сокетов, количество ядер на сокет.

Отдельно запишите, по какой версии Core Factor Table считаете: дату публикации (или дату скачивания) и где документ хранится внутри компании. Это лучше указывать прямо в шапке таблицы, чтобы через полгода никто не пересчитывал по другой версии и не получал иные числа.

Если в одном сервере стоят разные CPU (редко, но бывает после замен), не усредняйте. Разбейте сервер на две строки по группам CPU и применяйте коэффициент к каждой группе отдельно.

Чтобы расчет был проверяемым, заведите таблицу со столбцами:

• хост/сервер, роль;
• CPU model, сокеты, cores per socket, итого cores;
• Core Factor (с указанием источника);
• итог Processor = cores x Core Factor (с округлением по правилам учета).

Так вы заранее уберете главную причину споров: разные трактовки модели CPU и коэффициента.

Шаг 4: описать виртуализацию и границы лицензирования

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

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

Что нужно зафиксировать по виртуальной среде

Не пытайтесь описать все детали платформы. Соберите минимум, который влияет на границы:

• технология виртуализации и режимы миграции (есть ли live migration, куда может перемещаться ВМ);
• состав кластера: список хостов, на которых ВМ с Oracle может быть запущена;
• ограничения ресурсов ВМ: vCPU, лимиты/резервации, есть ли жесткая привязка к хосту;
• правила размещения: DRS/автораспределение, affinity/anti-affinity;
• данные про закрепление CPU (pinning, processor affinity), если вы используете это как техническую границу.

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

Пример, который помогает не ошибиться

Есть ВМ DB-PROD на VMware. Сейчас она работает на Host-03, но кластер состоит из 8 хостов, и включен автоматический перенос для балансировки. В исходных данных граница должна быть описана как «кластер из 8 хостов (перечень), Oracle установлен и используется на DB-PROD, возможная миграция на любые хосты кластера». Если настроен жесткий pinning к двум хостам, это фиксируется отдельно и подтверждается настройками, иначе расчет будет спорным.

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

Шаг 5: окружения, DR и правила учета

Перед расчетом зафиксируйте, что именно вы называете отдельной средой. Обычно это prod, test, dev, training и DR. Ошибка на этом шаге делает цифры несопоставимыми с реальностью: люди говорят про одно и то же, но подразумевают разные вещи.

Для каждой среды опишите ее смысл простыми словами: зачем она существует, кто владелец (подразделение и ответственный), когда она работает (24/7 или по рабочим часам), кто имеет доступ (админы, разработчики, подрядчики), есть ли ограничения на подключение.

Отдельно пометьте DR (резервный контур). Укажите, горячий он или холодный, как часто поднимается, есть ли план тестов. Например: «холодный DR, старт только по аварии, тест раз в квартал на 4 часа» или «горячий DR, синхронная репликация, тест переключения раз в месяц». Без этого один человек считает DR как полноценный прод, другой - как выключенный запас.

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

Чтобы избежать разночтений, согласуйте единые названия сред и придерживайтесь их в инвентаризации:

• prod, test, dev, training, staging, dr-hot, dr-cold;
• единый формат имени: система-среда-локация (например, fin-prod-ast);
• правило: название в CMDB и в таблице расчета должно совпадать.

Шаг 6: как собрать данные для Named User Plus

Для расчета NUP важно не «угадать» число, а собрать подтверждаемые исходные данные. Обычно считают не только сотрудников, которые заходят в базу напрямую, но и тех, кто получает доступ через приложения. Отдельно учитывают технические учетные записи, если они дают доступ к функционалу БД.

Сначала договоритесь о трактовке «пользователя» для вашего случая. Проверьте, есть ли прямой доступ (SQL-клиенты, админ-инструменты), доступ через приложение (ERP/CRM/веб-портал), сервисные интеграции (шины данных, ETL, мониторинг), общие логины.

Практичный набор источников, которые стоит выгрузить и сверить:

• IAM/AD: группы, у которых есть право на приложение или на БД;
• список приложений и владельцев: кто реально использует функции, которые ходят в Oracle;
• учетные записи в БД: активные пользователи, роли, последние логины (если доступно);
• сервисные аккаунты и интеграции: какие системы подключаются и зачем;
• документация по доступам: заявки, матрица ролей, регламенты.

Отдельная ловушка - косвенный доступ. Если 500 сотрудников работают в приложении, а приложение ходит в БД под одним общим логином, это не превращает 500 человек в 1 NUP. Фиксируйте «входные группы» в приложении и сопоставляйте их с теми, кто фактически может получить данные из Oracle.

Зафиксируйте метод подсчета и дату снимка (например, «по активным пользователям за последние 90 дней плюс все сервисные интеграции»). Это упрощает повторный расчет и объяснение цифр при проверке.

В конце проверьте минимальные требования по NUP для выбранного издания и сценария (они зависят от конфигурации и правил Oracle). Если ваш расчет ниже минимума, в итог берут минимум.

Пример: у отдела продаж 120 пользователей в CRM, CRM подключается к Oracle под одной учетной записью, плюс 3 интеграции (ETL, отчетность, мониторинг). В исходные данные вы заносите 120 как пользователей приложения с косвенным доступом и отдельно отмечаете 3 сервисные учетные записи, затем проверяете минимум и принимаете большее значение.

Типовые ошибки, из-за которых расчет ломается

Ошибки в исходных данных часто выглядят как мелочи, но быстро превращаются в лишние лицензии или, наоборот, в недолицензирование.

Самая частая путаница - vCPU и физические ядра. В отчетах виртуализации проще всего увидеть vCPU, а для Processor обычно нужны физические характеристики хоста и модель CPU, чтобы корректно применить коэффициенты. Если модели процессора нет, вы не можете уверенно выбрать нужный factor.

Ошибки по инфраструктуре

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

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

Ошибки по пользователям и средам

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

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

Быстрый чек-лист перед расчетом

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

Проверьте инвентаризацию и железо

Если хотя бы один хост выпал из списка, расчет почти всегда занижен.

• Собран единый список всех мест, где Oracle реально установлена или может быть развернута: физические серверы, хосты виртуализации, кластеры, узлы для миграций.
• По каждой системе зафиксированы сокеты, число физических ядер, точная модель CPU и источник этих данных.
• Для каждой модели CPU определен Core Factor и отмечено, по какой таблице и на какую дату он взят.

Проверьте виртуализацию, окружения и NUP

Сначала договоритесь о правилах, потом подставляйте числа.

• Описана виртуализация и границы лицензирования: где возможны перемещения ВМ, какие хосты входят в потенциальный пул.
• Все окружения подписаны одинаково во всех источниках (prod, test, dev, DR) и подтверждены владельцами, включая спорные случаи (например, тест, который иногда становится боевым).
• Для DR указано: активный он или холодный, как часто включается, есть ли репликация, и кто подтверждает режим.
• Для NUP выбран метод подсчета и закреплены источники: IAM/AD, HR, реестры приложений, отчеты по доступам.
• Отдельно отмечены опции и пакеты Oracle, которые используются фактически (а не только «установлены»). Например, включенный Partitioning или Diagnostics может изменить итог.

Самопроверка: если вы можете открыть одну таблицу и по любому серверу за 30 секунд ответить «какая модель CPU, сколько ядер, какой factor, где граница кластера, какое окружение и откуда NUP», значит данные готовы.

Пример сценария: как подготовить таблицу исходных данных

Типичная картина: два физических сервера в одном кластере виртуализации, несколько ВМ под Oracle Database для prod и test, плюс отдельная площадка DR, где ВМ включаются только на учениях или при аварии. Чтобы расчет не превратился в спор, сначала собирают одну «таблицу истины» и согласуют ее с владельцами.

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

• система (prod/test/dev), площадка (DC1/DC2/DR) и владелец (ФИО/подразделение);
• физический хост: модель CPU, количество сокетов, ядер на сокет, включен ли HT;
• виртуализация: кластер/пул, привязки (pinning), правила миграции, список возможных хостов для ВМ;
• ВМ: vCPU, лимиты/резервации, фактическое размещение и «куда может переехать»;
• Oracle: редакция/опции, где установлено, где реально запускается, режимы DR (active/passive).

Кто подтверждает данные: инфраструктуру (виртуализацию и границы кластеров) обычно подтверждает команда платформы, CPU и железо - системные инженеры, фактическое использование Oracle (инстансы, опции, окружения) - DBA.

Промежуточный расчет Processor (без цифр) выглядит так: определяете, какие физические ядра попадают в границу лицензирования (все хосты кластера или только закрепленные), умножаете количество ядер на коэффициент из Oracle Core Factor Table для конкретной модели CPU, затем округляете по правилам Oracle и получаете количество Processor лицензий.

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

Чтобы закрыть пробелы, задайте владельцам систем несколько прямых вопросов:

• может ли ВМ мигрировать на любой хост кластера, и есть ли запрет на миграцию;
• DR запускается постоянно или только при аварии/тестах, и как часто это происходит;
• какие приложения и внешние системы ходят в базу (включая batch, API, интеграции);
• какие опции Oracle включены фактически, а не «на всякий случай» в документации;
• что считается prod, а что test, и есть ли копии prod в других средах.

Такой шаблон обычно снимает большую часть споров о том, что именно считать.

Следующие шаги: как закрепить расчет и не потерять актуальность

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

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

Дальше подготовьте пакет подтверждений для внутреннего аудита и диалога с вендором:

• выгрузки из CMDB/инвентаризации и перечень хостов с точками установки;
• отчеты по CPU и числу ядер (с указанием модели процессора);
• подтверждение настроек виртуализации и границ (кластеры, пулы, политики);
• описание окружений (prod, test, dev, DR) и правила учета для них;
• материалы по спорным местам (например, настройки привязки к хостам).

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

Чтобы расчет не устарел, заранее договоритесь о триггерах обновления: новый хост, миграция в другой кластер, апгрейд CPU, изменение настроек виртуализации, добавление DR-площадки. Для каждого триггера назначьте срок обновления данных и ответственного.

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