Tantos los contratos como las políticas de licenciamiento de Oracle (ej. Oracle Partitioning Policy) pueden convertirse en un campo de minas en los que si el cliente cae, se enfrenta a exposiciones financieras y de cumplimiento.
Pero de todas las trampas existentes en licenciamiento Oracle, es el licenciamiento de entornos virtualizados el causante:
- de los procesos de auditorías de software más agresivos y desagradables
- de las reclamaciones más salvajes por parte de Oracle que hemos conocido
- de certificaciones erróneas de ULA de Oracle que pueden costarnos muy caras
Y cuando hablamos de reclamaciones salvajes, nos referimos a alguna que ha llegado incluso a los ocho ceros y muchas a los siete: en Evergreen Compliance somos ex auditores del fabricante 100% independientes y hemos vivido estas auditorías desde ambos lados del tablero.
La comprensión de este artículo permitirá entender mejor no solo la Oracle Partitioning Policy y su valor, sino la perspectiva de Oracle con relación a este tema, cuál es su punto de vista en la práctica y qué estrategias están resultando más eficientes para proteger los intereses de los clientes durante este 2023:
Qué es la Oracle Partitioning Policy
Es un documento publicado en la web de Oracle que tiene como objetivo proporcionar directrices relativas a políticas de licenciamiento para sus productos de tecnología (ej. base de datos o middleware) en:
- Entornos virtualizados: Hard y Soft Partitioning
- Oracle Engineered Systems: Trusted Partitions y Capacity on Demand (para saber más de Exadata Licencsing, pinche aquí)
- Contenedores y clusters de Kubernetes
En el presente artículo únicamente nos centraremos en el licenciamiento de entornos virtualizados: Para saber más sobre los retos de licenciamiento en entornos virtualizados, pinche aquí.
Al pie del documento encontramos información adicional importante sobre qué es y qué no. La Oracle Partitioning Policy por tanto es una guía que:
- Proporciona directrices relativas a las políticas de Oracle vigente a partir de 14 de febrero de 2020: es la versión vigente en agosto de 2023
- Tiene únicamente fines educativos
- No puede incorporarse a ningún contrato
- No constituye un contrato ni compromiso con ninguna condición específica
- Está sujeta a cambios sin previo aviso: de hecho existen diferentes versiones del documento a lo largo del tiempo
Qué dice la Oracle Partitioning Policy
La finalidad del documento es definir qué tecnologías de virtualización son susceptibles de limitar el número de licencias Processor requeridas (=sub-capacidad) al permitir que no se tengan que licenciar la totalidad de los cores físicos del servidor o de un conjunto de servidores.
Dicho de otra manera, frente al principio general de tener que licenciar todos los procesadores en los que el software Oracle está instalado o ejecutándose (tal y como se define en el contrato y que después veremos), la Oracle Partitioning Policy establece las condiciones que permiten la sub-capacidad y por tanto que únicamente se tengan que licenciar algunos cores físicos del servidor o cluster de servidores y no la totalidad de ellos.
En este sentido, Oracle establece unilateralmente la siguiente diferencia:
Soft Partitioning
Se caracteriza por:
- Ser tecnologías que no segmentan físicamente sino lógicamente (ej. a través de gestores de recursos del SO) lo que permite una gestión flexible de los recursos al poderse modificar fácilmente la capacidad de procesador según se necesite.
- No estar reconocido por Oracle para determinar o limitar el número de licencias Processor necesarias para cubrir un servidor o cluster de servidores.
- Ser el principio que aplica por defecto: todo lo que no sea definido explícitamente como Hard Partitioning, es considerado Soft Partitioning.
- Incluye VMware que es la tecnología de virtualización más exptendida en el mercado.
Hard Partitioning
Se caracteriza por:
- Ser tecnologías que segmentan físicamente el servidor en sistemas diferentes más pequeños que actúan a su vez como un servidor físicamente independiente con sus propios cores, SO, almacenamiento y recursos de red.
- Sí están reconocidos por Oracle para delimitar o limitar el número de licencias Processor necesarias para cubrir un servidor o cluster de servidores.
- Deben tener obligatoriamente un número máximo o capado de cores o procesadores asignados a cada partición.
- Ser únicamente los enumerados expresamente en la Oracle Partitioning Policy:
- Physical Domains, también conocidos como PDomains, Dynamic Domains o Dynamic System Domains
- Solaris Zones o Solaris Containers, solo si se cumplen ciertas condiciones
- LPAR de IBM
- Micro-Partitions de IBM
- vPar
- nPar
- Integrity Virtual Machine
- Secure Resource Partitions
- PPAR de Fujitsu
- Oracle Linux KVM
- Oracle VM Server for x86 solo si se cumplen ciertas condiciones
- Oracle VM Server for SPARC solo si se cumplen ciertas condiciones
Qué dice el contrato
Como hemos visto, la propia Oracle Partitioning Policy dice que es un documento con fines educativos sin ningún valor contractual.
Hay que tener siempre en cuenta que el contrato con Oracle está únicamente formado por:
- OMA (Oracle Master Agreement):
- TOMA (Transactional Oracle Master Agreement): es el más frecuente
- Five-year-term Master Agreement
- Documento de pedido
- El contenido de las URLs a los que remite la documentación contractual:
- Processor Core Factor Table
- Oracle Support Policy
- Es una buena práctica incorporar el contenido físico de estas páginas al contrato para evitar modificaciones unilaterales de obligaciones o derechos contractuales por parte de Oracle
En el contrato, por tanto:
- Por una parte, no se incorpora la Oracle Partitioning Policy
- Por otra, la métrica Processor “se define como todos los procesadores en los que están instalados y/o en ejecución los Programas Oracle”
De esta definición resultan las siguientes cuestiones importantes:
- En realidad, el software de Oracle no se instala en procesadores sino en discos.
- En la práctica por tanto la definición queda limitada a los procesadores en los que se está ejecutando el software de Oracle.
- Es relevante aquí el tiempo verbal presente que se usa en el contrato al exigirse solamente que se licencien todos los procesadores en los que esté “corriendo” o “en ejecución” (no en los que “pudieran llegar a ejecutarse” aunque no lo esté haciendo ahora) el software de Oracle.
Qué dice LMS
LMS, que es la división de Oracle encargada de las auditorías y el cumplimiento, tiene su propia interpretación (evidentemente la que más le conviene) de la definición contractual de métrica Processor ya vista:
- Consideran que “instalado” significa que los binarios del software se encuentran en un disco o array de disco.
- Consideran que “corriendo” o “en ejecución” significa que el software está configurado de tal manera que operativamente pueda usarse, aunque no se esté usando.
- Consideran que la Oracle Partitioning Policy (que no tiene valor contractual) es de obligado cumplimiento, prevaleciendo por tanto sobre todo lo demás.
- En la práctica, por ejemplo en caso de VMware, esto lleva a que LMS en una auditoría:
- Asuma automáticamente por defecto que todos los procesadores de un vCenter se están utilizado para ejecutar los programas de Oracle y que por tanto hay que licenciarlos.
- En lugar de investigar si los programas de Oracle realmente se han ejecutado alguna vez en hosts sin licencia dentro de un vCenter (para lo cual por ejemplo podría ser útil facilitar los eventos de vMotion)
El Problema
El problema aquí es doble:
- El conflicto entre los términos del contrato y el contenido de un documento con fines educativos sin valor contractual (Oracle Partitioning Policy).
- La interpretación de la cláusula contractual de métrica Processor.
La interpretación que hace LMS de lo que significa “en ejecución” o “ejecutándose”, junto con la aplicación de la política de Soft Partitioning, lleva a conclusiones que encajan difícilmente con la interpretación literal de la definición contractual de Processor, ya que se obliga a licenciar cores en los que el software de Oracle no se está ejecutando (y en los que muchas veces no se puede ni ejecutar técnicamente), simplemente porque existe la posibilidad.
Esta lectura también choca incluso con la interpretación literal de lo que dice la Oracle Partitioning Policy cuando señala que su contenido implica una excepción frente al principio general, marcado por la definición contractual de Processor, de tener que licenciar todos los procesadores en los que el software Oracle está ejecutándose al permitir que únicamente se tengan que licenciar una parte –se entiende de aquéllos en los que se esté usando el software- y no todos. Lo que lleva a la siguiente paradoja:
- En lugar de cumplir el Oracle Partitioning una función de “seguro” o “garantía” para que el cliente tenga la certeza de bajo qué condiciones se acepta la sub-capacidad en entornos virtualizados.
- Su interpretación, por parte de Oracle, está posibilitando que el Oracle Partitioning Policy se utilice para “contagiar” la obligación de licenciar a cores en los que el software no está instalando ni ejecutándose (contraviniendo así la definición contractual de Processor) simplemente porque existe la posibilidad y con la excusa de encuadrarse la tecnología de virtualización bajo la categoría de Soft Partitioning.
Haciendo una analogía, es como si recibimos una multa de tráfico, no por la velocidad real que hemos alcanzado sino únicamente por la máxima que marca el velocímetro de nuestro coche aunque éste esté estacionado.
Cómo defenderse frente a Oracle en 2023
En la práctica, para conseguir que Oracle pueda aceptar un escenario de sub-capacidad en entornos calificados de soft partitioning, lo más eficaz es:
- Recordar la definición contractual de métrica Processor y su interpretación literal (no la interesada que plantea Oracle)
- Implantar medidas de aislamiento tanto a nivel de red como de almacenamiento que sean ajenas a la propia tecnología de virtualización
- Acreditar debidamente que, con dichas medidas de aislamiento de red y almacenamiento (nunca de la propia tecnología de virtualización) presentadas, es absolutamente imposible que una MV con Oracle pueda moverse a otro servidor o cluster de servidores que no se quiera licenciar.
Es importante advertir que:
- Las medidas concretas de aislamiento de red o almacenamiento pueden variar según el caso concreto, por lo que no hay una bala de plata que sirva para que Oracle reconozca siempre la sub-capacidad.
- Oracle nunca va a aceptar por sí solas medidas de aislamiento de la propia tecnología de virtualización para reconocer la sub-capacidad en entornos calificados de soft partitioning:
- Pueden servir eventualmente como complemento o para reforzar la medida de aislamiento «externa» de red y almacenamiento
- Pueden servir para preconstituir prueba de forma que se pueda acreditar que nunca se ha movido una MV a ciertos servidores o clusters, pero siempre que se presente junto a una medida de aislamiento «externa» aceptable de red y almacenamiento (acompañándose de información adicional de trazabilidad de MVs como eventos de vMotion por ejemplo)
- Oracle en ningún caso va a reconocer las medidas que ciertos fabricantes proponen a nivel lógico, por ejemplo VMware con reglas de afinidad o similares (aquí o aquí), para conseguir sub capacidad en entornos de Soft Partitioning.
- Lo que sí es posible, y siempre recomendable sobre todo en caso de ULA (aquí y aquí), es negociar contractualmente con Oracle:
- cómo llevar a cabo la medición de licencias en entornos virtualizados considerados Soft Partitioning (por ejemplo Oracle no tiene publicado ningún documento donde se explique cómo se licencia Oracle en entornos de VMware)
- qué medidas de aislamiento autoriza
- cómo deben aplicarse para que se reconozca la sub-capacidad.
Conclusión
Los contratos y políticas de licenciamiento de Oracle son complejos, precisamente porque esto beneficia a Oracle, y requieren para su debida comprensión de conocimiento especializado y mucho tiempo: La Oracle Partitioning Policy es el perfecto ejemplo de ello.
Adentrarse en licenciamiento sin la debida preparación y experiencia, puede llevar a caer en alguna de las numerosas trampas que permiten a Oracle montar una reclamación para terminar exigiendo al cliente que compre lo que en la mayoría de casos ni quiere ni necesita: ¿Se imagina el precio de licenciar todos los hosts de un vCenter (o varios) simplemente porque haya una MV con Oracle alojada en un único host?
En Evergreen Compliance, lo sabemos bien y nuestros clientes también: somos ex auditores del fabricante, 100% independientes y solo en 2023 hemos neutralizado exposiciones financieras por incumplimiento de licenciamiento Oracle de varias decenas de millones de Euros.
Si quiere saber más, revise nuestros casos de éxito, White Papers o contáctenos sin compromiso para saber cómo ayudamos a nuestros clientes a caminar sobre un suelo firme para exprimir sus inversiones en activos de software y eliminar riesgos de incumplimiento en licenciamiento Oracle.
