Лицензирование Oracle под VMware vSphere

Доля тяжёлых RISC-системы падает (из RISC-овых архитектур растёт только ARM), а вот x86 занимает всё больше ниш, в том числе с такими ресурсоёмкими приложениями, как Oracle DB.

На данный момент  у меня Oracle DB работает на серверах с архитектурой IBM Power7. Данная платформа имеет отличную фишку по экономии средств на лицензирование СУБД за счет использования hard partitioning в соответствии с Oracle Partitioning Policy. При создании виртуальной машины (LPAR) в IBM PowerVM достаточно указать, что процессоры “выделенные” (Dedicated), не разрешать живую миграцию (Live Partition Mobility) и спокойно можно использовать 10 лицензий на 16 ядерном сервере.

А вот на плаформе x86 с политикой лицензирования Oracle полная каша. Возникает вопрос в определении  – что используется в текущий момент soft или hard partitioning? Ответ не так прост, так как всё зависит от настроек.

Честный hard partioning на платформе x86

Вариантов мне известно два:

  • Использование серверов Fujitsu или Hitachi с функцией logical partitioning.
  • Отключить процессор в BIOS/UEFI.

Hard partioning на платформе x86 для своих

Использование CPU Affinity в Oracle VM. Также рекомендую статью Hard and Soft Partitioning with Oracle VM.

Для Microsoft Azure разрешена license mobility.

Альтернативное лицензирование

Специальная политика лицензирования для облачных провайдеров.

Как превратить soft partitioning в hard при использовании VMware vSphere?

VMware выпускает специальный документ Understanding Oracle Certification, Support and Licensing for VMware Environments, который даёт ответ, что использованиие CPU Affinity по аналогии с Oracle VM позволяет лицензировать под Oracle DB только используемые ядра.
Юридическая сторона вопрос разобрана специалистами компании House of Brick Technologies, занимающейся аудитом использования лицензий, в статье Oracle Licensing: Soft Partitioning on VMware is Your Contractual Right.

Вывод

Для легального использования лицензий Oracle DB по количеству используемых ядер в виртуальной среде VMware vSphere необходимо:

  • отключить применение технологий vMotion, DPM, DRS для виртуальных машин с Oracle DB;
  • назначить посредством CPU Affinity необходимое количество ядер виртуальной машине, при включенном HT – можно добавлять допольнительно нечётные ядра;
  • в случае аудита лицензий, должна быть возможность трекинга перемещений виртуальной машины, что можно выполнить в vSphere без особых проблем.

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

Осталась ещё одна функия – HA, с точки зрения использования Oracle VM нет прямого запрета в документах Oracle использовать данный функционал и он разрешен, а вот VMware считает это перемещением виртуальной машины и советует отключать.

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

3 thoughts on “Лицензирование Oracle под VMware vSphere”

  1. интересная статья, у нас была база оркл на p750 с двумя 8ми ядерными Power7, в силу того что не кто не знал не IBM ни AIX не Oracle а обслуживание покупать дорого, мы мигрировали на x86 с вмваре, сейчас база живёт на bl660 с 4мя E5-4650 и 256 гб ram, в итоге ВМ базы занимает всё лезвие, и не паремся, производительность выше (на вопрос почему базу не поставили на чистое железо – потому что в вмваре гео кластер) в плане лицензирования история умалчивает)

  2. В РФ редко бывают аудиты на соблюдение лицензионной чистоты использования ПО. Если есть хотя бы часть лицензий – вендор уже радуется.
    Поддержку покупает небольшая часть покупателей.
    Нам же крайне желательно иметь сквозную лицензионную чистоту ПО и совместимые конфигурации оборудования, использованного при производстве изделий.
    Формально несоблюдение количества ядер может выйти боком на этапе обращения в поддержку. А вот настройки кластера VMware или vMotion никак не проверить, кроме аудита специалистами.

    По поводу перехода на x86, мы считаем, что для нашей нагрузки достаточно и 2-сокетных серверов, так как ядер-то уже доступно по 18 штук.

Leave a Reply

Your email address will not be published. Required fields are marked *