En esta guía «Licensing Oracle on Azure» se profundiza en las diferentes opciones existentes a la hora de llevar cargas de trabajo Oracle a Azure y su impacto a efectos de licenciamiento.
Cualquier malentendido en las políticas o términos y condiciones aplicables, puede detonar incumplimientos que comprometan definitivamente el retorno de inversión (ROI) previsto de nuestra migración a cloud.
Y es que el uso de licencias Oracle en Azure en ningún caso excluye la posibilidad de que exista un incumplimiento de los términos y condiciones de la licencia, por lo que es objeto de revisión en las auditorías de licencias de LMS y de sanción por parte de Oracle cuando se detecta alguna irregularidad.
Seguidamente procedemos a analizar el régimen de licenciamiento Oracle aplicable cuando se trabaja en Azure, qué metodologías de cómputo de licencias deben utilizarse y el impacto en licenciamiento de cada supuesto con sus principales riesgos.
Regla General: el contrato
Cuando se trata de llevar licencias Oracle (ej. base de datos o middleware) a Azure, la definición de métrica de licencia Processor o NUP (Named User Plus) de nuestro contrato (que depende de las características de la infraestructura subyacente) puede servir de poco en entornos cloud multi-tenant: En el contrato con Oracle (donde se incluye la definición de métrica Processor y Named User Plus) no se prevé expresamente el licenciamiento de sus productos en cloud.
Lo que sí establece el contrato, en el ámbito del licenciamiento de bases de datos, es lo siguiente:
- Oracle Enterprise Edition
- Puede licenciarse en métrica Processor o NUP:
- Processor. Se caracteriza por:
- El número de licencias requeridas se obtiene sumando todos los cores en los que está instalado/ejecutando Oracle y multiplicando esa cifra por el factor aplicable según el Core Factor Table
- NUP. Se caracteriza por:
- Mínimo de 25 NUP por Processor
- Processor. Se caracteriza por:
- Puede licenciarse en métrica Processor o NUP:
- Oracle Database Standard Edition 2:
- Puede licenciarse en métrica Processor o NUP:
- Processor. Se caracteriza por:
- No aplica Core Factor Table
- Un socket ocupado equivale a un Processor
- NUP. Se caracteriza por:
- Mínimo de 10 NUP por servidor
- Solo puede licenciarse en servidores que tengan una capacidad máxima de 2 sockets
- Cada base de datos Standard Edition 2 puede usar un máximo de 16 CPU threads en cualquier momento
- Processor. Se caracteriza por:
- Puede licenciarse en métrica Processor o NUP:
Desde el punto de vista estrictamente contractual, en Oracle no existe ninguna disposición particular ni política (ej. Oracle Partitioning Policy) que nos permita acogernos a una metodología de cómputo de licencias requeridas más beneficiosa que la vista para métrica Processor o NUP según la edición del producto de base de datos aplicable (Enterprise Edition o Standard Edition).
La Excepción a la Regla General: “Licensing Oracle Software in the Cloud Computing Environment
La política “Licensing Oracle in the Cloud Computing Environment”:
- Ni es un contrato ni forma parte del contrato ni tiene valor contractual, únicamente tiene propósitos educativos.
- Tiene como objeto proporcionar directrices relativas a las políticas de licenciamiento Oracle para ciertos programas y en ciertos entornos cloud
- Es una excepción al principio general establecido en el contrato con relación a lo dispuesto en la definición de métricas (Processor y NUP) para la determinación del número de licencias necesarias y la regla de mínimos.
- Aplica únicamente a ciertos productos de Oracle, pero no a todos (están excluidos por ejemplo RAC (Real Application Clusters) y Rac One Node
- Aplica únicamente a ciertos entornos de computación cloud (“Authorized Cloud Environments”)
- Oracle considera Azure “Authorized Cloud Environment”.
Sub-capacidad y método de cómputo de licencias Oracle en Azure
La finalidad del documento “Licensing Oracle in the Cloud Computing Environment” es:
- Reconocer las condiciones que permiten limitar el número de licencias Processor y NUP requeridas (=sub-capacidad) en Azure de modo que no se tengan que licenciar la totalidad de cores físicos (o en su caso sockets ocupados) del servidor en los que se esté ejecutando el software de Oracle.
- Definir la metodología de cómputo de las licencias Processor y NUP necesarias.
A partir de aquí, Oracle establece unilateralmente en su política ‘Licensing Oracle Software in the Cloud Computing Environment’ la siguiente diferencia entre las diferentes ediciones de su base de datos:
Oracle Database Enterprise Edition Licensing on Azure
Para el licenciamiento de programas Enterprise (solo los incluidos en la lista, por ejemplo Oracle Database Enterprise Edition), en entornos los ‘Authorized Cloud Environments’, deberá tenerse en cuenta:
- El número máximo de vCPUs disponibles de la instancia (con independencia de su uso real) en que se ejecute el software de Oracle.
- Si el multi-threading está activo, 2 (dos) vCPUs disponibles de la instancia, equivalen a 1 (una) licencia Processor.
- Si el multi-threading no está activo, 1 (un) vCPU disponible de la instancia, equivale a 1 (una) licencia Processor.
- No se tiene en cuenta el Oracle Processor Core Factor Table.
- En caso de licenciamiento por Named User Plus (NUP), aplica el mínimo general de 25 NUPs por Processor.
Oracle Database Standard Edition Licensing on Azure
Para el licenciamiento de los programas Oracle Standard en entornos los ‘Authorized Cloud Environments’, deberá tenerse en cuenta:
- Para Oracle Database Standard Edition:
- Solo se autoriza Oracle Database Standard Edition en instancias de hasta 16 vCPUs: si hay más es necesario Oracle Database Enterprise Edition.
- A efectos de licenciamiento, se tiene en cuenta el tamaño de la instancia, de modo que 4 o menos vCPUs cuentan como un socket ocupado y por tanto como una licencia Processor.
- Si la instancia tiene más de 4 vCPUs, cada 4 VCPUs usadas (o si son menos, redondeadas al alza hasta el múltiplo de 4 más próximo), requiere de una licencia Processor adicional.
- Para Oracle Database Standard Edition One y Standard Edition 2:
- Solo se autoriza Oracle Database Standard Edition One y Standard Edition 2 en instancias de hasta 8 vCPUs: si hay más de 8 vCPUs hasta 16, es necesario Oracle Database Standard Edition; si hay más de 16 vCPUs es necesario Oracle Database Enterprise Edition.
- A efectos de licenciamiento, se tiene en cuenta el tamaño de la instancia.
- Si la instancia tiene más de 4 vCPUs, cada 4 VCPUs usadas (o si son menos, redondeadas al alza hasta el múltiplo de 4 más próximo), requiere de una licencia Processor adicional.
- En caso de licenciamiento por Named User Plus (NUP), el mínimo es de 10 NUP por cada 8 vCPUs.
Constrained vCPUs en Azure
Para compensar la prohibición del Oracle Core Factor Table, que en la práctica lleva por ejemplo a exigir en Oracle Database Enterprise Edition el doble de licencias que si nos fuéramos a Oracle Cloud Infrastructure (OCI), pueden contemplarse el uso de Constrained vCPUs en Azure.
Constrained vCPUs permite disponer de una instancia con un “número máximo disponible de vCPUs” reducido, y una reducción en el número de vCPUs implica también una reducción en el número de licencias Processor requeridas.
A título de ejemplo, vamos a hacer una comparativa con una MV Standard_E32s_v5:
| Tipo | Nombre | Número máximo disponible de vCPUs | Licencias Processor (EE) necesarias con Multi-threading Activo | Licencias Processor (EE) necesarias con Multi-threading Activo |
|---|---|---|---|---|
| Base (Original) | Standard_E32s_v5 | 32 | 16 | 32 |
| Constrained | Standard_E32-16s_v5 | 16 | 8 | 16 |
| Constrained | Standard_E32-8s_v5 | 8 | 4 | 8 |
Conflicto con LMS
Esta situación puede generar conflicto con Oracle ya que en ocasiones señalan que el “número máximo disponible de vCPUs” que aplica es el de la MV original (en el ejemplo con Standard_E32s_v5 serían 32 vCPUs) y no el “Constrained” (en el ejemplo Standard_E32-16s_v5 con 16 vCPUs y Standard_E32-8s_v5 con 8 vCPUs), y todo ello a pesar de:
- La literalidad de “For the purposes of licensing Oracle programs in an Authorized Cloud Environment, customers are required to count the maximum available vCPUs of an instance type” de la política.
- Del hecho de que el número de vCPUs disponibles en MVs con “constrained vCPUs” no puede alterarse.
Es un supuesto similar al de Optimize CPU Program en AWS, por lo que en caso de auditoría es siempre recomendable no compartir nunca demasiada información con LMS y trasladarles únicamente el “número máximo disponible de vCPUs” que es el dato objetivamente relevante para determinar el número de licencias requeridas según la Cloud Policy, evitando dar información sobre el uso concreto de Constrained vCPUs en Azure.
Conclusión
Entender cómo aplican los contratos y las políticas de Oracle cuando nos llevamos sus licencias (ej. base de datos o middleware) a Azure, es imprescindible para:
- evitar incumplimientos que nos expongan a riesgos legales y financieros desmedidos
- asegurar el control del gasto y un retorno óptimo de la inversión
Tanto si está planteándose la migración a Azure como si ya ha emprendido este camino, le ayudamos a conocer la situación del licenciamiento Oracle y el impacto que tendría cualquier acción que planee llevar a cabo, reduciendo el requerimiento de licencias Oracle a sus necesidades reales y mitigando cualquier riego de incumplimiento.
Contacte con nosotros sin ningún compromiso, conozca cómo hemos ayudado a otros clientes a conocer las implicaciones del Oracle Licensing on Azure y conviértase en nuestro próximo caso de éxito.
