Лицензии Oracle в ТЗ: какие параметры окружения запросить

Что именно нужно получить от ИТ, чтобы расчет был проверяемым

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

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

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

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

Простой пример: если указать только «VMware-кластер из 10 хостов», расчет могут сделать по всем 10. Если же ИТ подтвердит, что Oracle-ВМ закреплены за 4 хостами и это технически enforced, цифры будут другими, и их можно будет защитить.

Сначала уточните рамки: что лицензируем и для чего

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

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

Дальше перечислите конкретные продукты и редакции Oracle в периметре. Пишите не «Oracle Database», а точнее: Database Standard Edition 2 или Enterprise Edition. Отдельно перечислите опции и management packs, если они используются. Если уверенности пока нет, лучше прямо указать, что использование требует подтверждения.

Сразу определите, по какой метрике предполагается расчет для каждой позиции: Processor или Named User Plus. Полный расчет все равно потребует данных по серверам и виртуализации, но на уровне рамок важно понимать, что вы считаете допустимым и на каком основании.

Чтобы не спорить о базовых вещах, ответьте в ТЗ на пять вопросов:

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

Если вы легализуете prod и test сейчас, но через год планируете DR-площадку, это лучше прописать сразу. Иначе расчет будет только по текущей картине, а бюджет «всплывет» позже.

Параметры физического сервера: сокеты, ядра, модель CPU

Проверяемость часто ломается на уровне «железа». Важно однозначно связать лицензируемую установку Oracle с конкретными физическими хостами. Здесь же появляется типичная проблема имен: один и тот же сервер в разных системах называется по-разному (hostname, инвентарный номер, имя в мониторинге), и потом невозможно доказать, что считали одно и то же.

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

• идентификаторы: модель сервера, серийный номер или asset tag, локация (ЦОД/площадка), роль (prod БД, тест, DR);
• CPU: производитель и точная модель, число сокетов, число физических ядер на сокет;
• настройки CPU: включен ли Hyper-Threading/SMT (как справочная информация);
• ограничения ресурсов: есть ли hard partitioning, какая технология, чем подтверждается настройка (выгрузка/скриншот);
• ОС и управление: тип и версия ОС, установлен ли гипервизор, как он администрируется.

Отдельно определите, что считается «истиной». Например: «Количество ядер берется из данных производителя/инвентарной системы, а не из гостевой ОС виртуальной машины». Это снимает спор, когда в гостевой ОС видны только выделенные vCPU.

Если у вас два одинаковых сервера в одном ЦОД, но один под продуктив, а второй под тест, в таблице должны быть разные asset tag и разные роли. Тогда их нельзя случайно сложить как один объект или, наоборот, потерять один из серверов.

Виртуализация и кластеры: где Oracle может реально выполняться

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

Сначала попросите у ИТ описать платформу виртуализации и топологию. Для VMware vSphere, Hyper-V, KVM и других систем детали отличаются, но смысл один: показать реальную (и разрешенную) область миграции.

Полезно ввести в ТЗ понятие «границы лицензирования» и привязать его к входным данным:

• перечень кластеров и список всех хостов в каждом кластере (имя, сокеты, ядра, модель CPU);
• правила DRS/HA: включено ли автоматическое перемещение, есть ли affinity/anti-affinity, какие хосты считаются failover;
• где ВМ с Oracle разрешено запускать по правилам эксплуатации (allowed hosts, выделенный кластер);
• параметры ВМ с Oracle (vCPU, RAM) и ограничения, если они используются;
• подтверждения: выгрузки из vCenter/SCVMM/CMDB и при необходимости скриншоты политик.

Пример: кластер из 8 хостов, но Oracle разрешено запускать только на 2 выделенных, а перенос на остальные запрещен политиками и настройками. В ТЗ важно не просто написать «2 хоста», а приложить список этих хостов, описать, как именно блокируется перенос, и что происходит при аварии (куда поднимется ВМ). Тогда граница понятна обеим сторонам.

Высокая доступность и резерв: RAC, Data Guard, DR и тестовые среды

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

RAC и кластер БД

Если используется Oracle RAC, запросите простые факты: сколько нод, на каких хостах они размещены, какие ноды активны постоянно, а какие используются только для отказоустойчивости. Даже если часть нод обычно простаивает, важно понять, может ли на них запускаться инстанс и при каких условиях.

Data Guard, DR и тестовые среды

Для Data Guard важны параметры, а не название: физический или логический standby, режим (синхронный/асинхронный), где расположен standby (отдельный сервер, отдельный кластер, другая площадка). По DR зафиксируйте состав железа и сценарии: как часто планируются тестовые переключения, сколько времени база может работать на DR, кто дает команду на запуск.

Чтобы расчет не строился на догадках, попросите по каждой среде (Prod, Standby, DR, Test/UAT) заполнить:

• тип решения (RAC, single instance, Data Guard, без резерва);
• список хостов/кластеров, где инстанс может быть запущен;
• роли (active, passive, standby) и правила переключения;
• допустимое время работы при аварии и частота DR-тестов;
• кто администрирует и кто имеет право поднимать инстансы.

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

Опции и management packs: что именно используется в базе

Самая частая причина споров - не серверы, а включенные опции и management packs. Важно зафиксировать не только «Oracle Database есть», но и какие функции реально используются в каждом окружении.

Сначала соберите базовые сведения по каждой базе: версия Oracle Database, редакция (SE2 или EE), где развернута (хост или кластер). Это важно, потому что часть опций доступна только в Enterprise Edition, а management packs лицензируются отдельно.

Дальше перечислите опции и пакеты, которые включены или использовались хотя бы раз. Часто спорят о таких позициях, как Partitioning, Advanced Compression, Advanced Security, Database In-Memory, RAC, а также Diagnostic Pack и Tuning Pack.

Не опирайтесь на «со слов». Попросите у DBA подтверждения с датой и источником, например:

• версии и редакции по базам (из системных представлений Oracle);
• отчеты по использованию функций (например, DBA_FEATURE_USAGE_STATISTICS);
• признаки использования пакетов (например, AWR/ADDM отчеты для Diagnostic Pack, задачи SQL Tuning Advisor для Tuning Pack);
• параметры и конфигурации (компрессия, партиционирование, RAC-конфигурация).

В самом ТЗ задайте правило: считать отдельно базовую лицензию Oracle Database и отдельно каждую опцию/пакет, с явными допущениями. Так проще сравнить расчет с вашей инвентаризацией.

Отдельно проговорите ситуацию, когда функции отличаются по средам. Например, в prod включены Partitioning и Compression, а в test они выключены и не используются. Если это не отражено в исходных данных, опции часто считают на все окружения, и сумму сложно оспорить.

Processor или Named User Plus: какие данные нужны для выбора

Метрику лучше зафиксировать прямо в ТЗ. Иначе расчет сделают «как удобнее», а проверить будет трудно.

Named User Plus (NUP) подходит, когда круг пользователей ограничен и его реально посчитать. Для проверяемого расчета нужен не «примерно 200 человек», а источник и метод подсчета: кто подключается к базе напрямую или через приложение, могут ли внешние системы выполнять запросы.

Для NUP обычно нужны:

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

Processor чаще выбирают, когда пользователей много, доступ идет через общие приложения, или интеграций так много, что NUP превращается в спор. Тогда решают инфраструктурные факты: на каких серверах Oracle может реально выполняться, включая кластеры, миграции и failover. Для этого в ТЗ нужны сокеты, ядра, модель CPU и список хостов/кластеров, где запуск Oracle разрешен политиками и настройками.

Практичное правило: если ИТ не может уверенно подтвердить число пользователей и всех «нечеловеческих» подключений, попросите расчет в двух вариантах - NUP и Processor - с явными допущениями и списком того, что нужно уточнить для финального выбора.

Как оформить входные данные в ТЗ: таблицы и допущения

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

Обычно хватает двух таблиц и короткого раздела с требованиями к формату результата.

1) Таблица исходных данных (факты)

Выберите единицу учета (строка на хост или строка на кластер) и держите ее одинаковой по всему документу. Минимальные колонки:

• объект (хост/кластер/пул) и роль (prod/test/dev);
• CPU (модель, сокеты, физические ядра, признак Hyper-Threading);
• виртуализация (платформа, есть ли миграция vMotion/Live Migration);
• Oracle (продукт/редакция, метрика Processor или NUP);
• ограничения (где можно запускать Oracle: да/нет, список разрешенных хостов).

2) Таблица допущений (что и почему)

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

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

В ТЗ также стоит требовать формат результата: расчет построчно, с формулами, коэффициентами, промежуточными итогами и пояснением каждого шага. Например, если написано «кластер из 6 хостов, Oracle разрешен только на 2», в расчете должно быть видно, почему лицензируются 2 (если запрет миграции подтвержден) или 6 (если запрета нет).

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

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

Типичные ошибки:

• описывают только текущее размещение ВМ («Oracle на ESXi-03»), но не фиксируют, куда она может мигрировать. В кластере с vMotion/DRS расчет обычно делают по всему пулу, если ограничения не прописаны;
• забывают про standby и DR. Сервер может быть выключен большую часть времени, но если он включается на учениях или проверках, это нужно описать режимом использования;
• не фиксируют опции и packs. Часто говорят «не используем», но функция включена и лицензируется отдельно;
• смешивают prod и test в одном кластере без жестких правил перемещения, из-за чего границы лицензирования размываются;
• нет даты «среза» и контроля изменений: пока согласуют ТЗ, добавляют хост, меняют CPU или расширяют кластер, а расчет остается по старой картине.

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

Короткий чеклист перед отправкой ТЗ поставщику

Перед отправкой проверьте, что входные данные можно перепроверить.

• есть полный перечень площадок, кластеров и хостов, где Oracle может оказаться (включая test, DR и временные зоны миграций);
• по каждому хосту зафиксированы сокеты, физические ядра и точная модель CPU;
• по виртуализации описаны правила, влияющие на размещение: DRS/HA, миграции, affinity/anti-affinity, закрепление, запреты;
• список продуктов Oracle и опций подтвержден DBA или инвентаризацией, а не «со слов»;
• в ответе поставщика требуется таблица исходных данных и отдельным блоком все допущения.

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

Пример простого окружения и как по нему проверить расчет

Представим типовую схему: Oracle Database работает как ВМ в VMware-кластере из 4 хостов, а на отдельной площадке есть DR со standby базой. Задача - описать это так, чтобы расчет можно было повторить по тем же данным.

Сценарий (одним абзацем)

Prod: одна ВМ с Oracle DB, которая может мигрировать по всему VMware-кластеру. Test: отдельная ВМ в том же кластере, но с меньшими ресурсами. DR: Data Guard standby на другой площадке, с заданным режимом (постоянно включена или включается только при аварии).

Чтобы убрать догадки, попросите ИТ ответить письменно:

• точный список ESXi-хостов в кластере и включены ли DRS/автомиграции;
• есть ли реально действующие ограничения миграции Oracle-ВМ (и кем утверждены);
• какие ресурсы выделены ВМ (vCPU, RAM, резервы/лимиты);
• как устроен DR: отдельный ли кластер, какие хосты, режим standby, частота переключений;
• какие опции Oracle используются и в каких средах.

Дальше разложите расчет на строки: prod, test, DR, и отдельными строками опции и management packs, с указанием метрики (Processor или NUP) и допущений о границах.

Проверка ответа поставщика сводится к трем вещам: совпадают ли списки хостов/кластеров, совпадают ли допущения про миграцию, отдельно ли посчитаны prod, test и standby. Если поставщик исключает часть хостов, пусть покажет основание (правило миграции, запрет, архитектурное решение) и кто это утвердил.

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

Чтобы расчет был воспроизводимым, важно договориться, кто отвечает за каждый блок данных и где хранится «истина». Лучше всего работает один шаблон для инфраструктуры, виртуализации и DBA и обязательная фиксация допущений.

Начните с владельцев данных: кто подтверждает состав кластеров, кто - конфигурации хостов, кто - фактическое размещение VM, кто - использование опций Oracle.

Рабочий порядок на 1-2 недели:

• соберите инвентаризацию из CMDB, vCenter/аналогов и отчетов DBA и сведите в одну таблицу с датой выгрузки и ответственным;
• согласуйте «границы лицензирования»: где Oracle может запускаться по правилам размещения, какие хосты исключены, какие кластеры доступны для миграции;
• зафиксируйте правила изменений: что считается нарушением (например, перенос VM в другой кластер без пересчета) и кто это согласует;
• попросите поставщика предоставить расчет в табличном виде: отдельная строка на сервер/кластер, отдельные столбцы для метрик и явный перечень опций и packs;
• проведите внутреннюю проверку на 1-2 узлах вручную, чтобы убедиться, что логика совпадает.

После этого соберите «папку подтверждений», чтобы через год повторить расчет без догадок: выгрузки из системы виртуализации (кластеры, хосты, настройки миграции) с датой, инвентаризацию железа (CPU, сокеты, ядра) с источником, подтверждение границ размещения Oracle-нагрузок, отчет DBA по опциям и packs, а также итоговый расчет поставщика с допущениями и версией правил.

Если данных много и они разбросаны по командам, иногда имеет смысл подключить системного интегратора. Например, GSE.kz может помочь с инвентаризацией инфраструктуры, консолидацией входных данных и подготовкой ТЗ так, чтобы расчет был проверяемым и выдерживал аудит.