martes, 19 de noviembre de 2013

Licenciamiento de Oracle en VMware

AVISO: este artículo es una opinión sin valor legal.

A principios de año un compañero, Sebastian Greco, escribió varios artículos sobre virtualización de Oracle. Un gran trabajo que me consta que sirve de referencia a empresas del sector, sobretodo el que hizo sobre licenciamiento. Es por eso que ha sido todo un reto escribir sobre este tema intentando aportar. Para conseguirlo he pedido ayuda: he consultado a auditor de licenciamiento de Oracle y a un abogado especialista en temas de TI a los que me gustaría dar las gracias desde aquí.

confusion
Licenciar Oracle sobre VMware es un tema confuso, ya que no trata simplemente de leer la documentación para aplicar la opción correcta, sino que no enfrentamos a una auténtica lucha entre dos multinacionales. Oracle no puede permitir que su producto estrella se virtualice más con otros Hypervisores (VMware) con el suyo propio (Oracle VM). Para colmo, al sur de los Pirineos nos encontramos con otra piedra en el camino, una cultural: está mal visto reclamar nuestros derechos.



Factores que han complicado todavía más escribir sobre este tema intentando ayudar. De todas formas espero que sirva incluso para aquellos que no quieren meterse en "líos".

De Menos a Más

Empezaremos con el licenciamiento por CPU de una maquina con Oracle en un único HOST ESXi.

CPU Affinity
Tal como aclaró Sebastian, vSphere es considerado como una tecnología de Soft Partitioning por Oracle, por lo que es necesario licenciar todas las CPUs del Host, aunque a la VM Oracle sólo presentemos una vCPU. Y no sólo eso, sino que VMware parece darlo por bueno en el documento donde intenta aclarar su postura sobre el licenciamiento de Oracle sobre su plataforma:


Y es que aunque defiende que su tecnología de CPU Affinity consigue que una máquina virtual sólo utilice ciertas CPUs, parecen haberse rendido al documento de Oracle sobre tecnologías de Partitioning. Documento que por otro lado no parece tener validez legal, como podemos ver en su pie de página:


Tal y como me comentó el abogado, no está tan claro que estos documentos no tengan validez legal, pero quizás en este caso sea menos relevante. Llegado el caso se podría interpretar que el software está "instalado o ejecutandose" en el Host (independientemente de maquinas virtuales), y por lo tanto será necesario licenciarlo por completo igualmente. 

"Instalado o ejecutandose" es la única aclaración que encontraremos en el contrato que firmamos con Oracle (de validez legal) llamado OLSA (Oracle License Service Agreement):


Sin entrar en opiniones sobre si la tecnología de CPU pinning de VMware es Soft o Hard, parece bastante claro que será necesario licenciar todas las CPUs del Host ESXi.

Host Affinity
¿Qué pasa si se trata de un cluster? Aquí las posturas no son tan uniformes, tal y como pude hablar con el auditor de Oracle su posición es simple: 

Para clusters VMware es necesario licenciar TODAS las CPUs de TODOS los Hosts 

Intenté discutir los detalles técnicos sobre que significa "software instalado" cuando nos movemos en un entorno SAN donde es sencillo presentar o despresentar LUNs o que pasaría si presentamos las LUNs con el software de Oracle a un subconjunto de Hosts del cluster, pero no hubo ni atisbo de discusión. Para Oracle se trata de una postura comercial firme, sin discusión.

Algo muy distinto a lo que nos dice VMware, que aclara que su tecnología DRS es capaz de limitar la ejecución de un equipo virtual a un subconjunto de nodos del cluster, algo que para ellos no tiene nada que ver con las tecnologías de Partitioning a las que hace referencia Oracle. Por lo tanto, para VMware será suficiente con licenciar el subconjunto de nodos del cluster que queramos utilizar para Oracle.

¿Cuál es mi opinión? además de utilizar DRS deberíamos presentar el disco donde esta instalado el software ÚNICAMENTE al los Hosts que queramos licenciar. Quizás estemos rizando el rizo pero, a falta de un mayor análisis, mi abogado de referencia parecía estar de acuerdo.

El Factor Cultural
Se trata de un conflicto comercial entre dos grandes empresas que no hace más que volver más interesante nuestros intentos de obtener lo mejor de sus productos.

Diversity quilt Un pugna que en otros países podría acabar en los juzgados sin que ello se perciba como un problema, sino un trámite como cualquier otro. Pero aquí las cosas son diferentes, un conflicto de este tipo no esta bien visto, además de que nos encontraríamos con unas consecuencias extremadas con respecto a otros países. 

Si estamos trabajando para un cliente local Oracle gana y si queremos reducir el coste de licenciamiento será necesario tirar de creatividad. Si trabajas para un cliente internacional infórmate de sus preferencias o directamente pregunta. 

Existen productos en el mercado que pretenden ayudarnos a saber si somos legales o no como el plugin para EM de Bluemedora, pero al final ya no se trata de una decisión de diseño sino de las preferencias del usuario final.

Licenciamiento Creativo

Cualquier piedra en el camino es una oportunidad para reinventarse, si ya hemos decidido que no queremos meternos en "lios" legales tendremos una de esas grandes oportunidades.

Volver a lo Básico
Cambiar a licencias por usuario o cambiar el hardware por uno más potente pero con menos cantidad de CPUs pueden parecer opciones muy evidentes, pero no podía obviarla. Un buen plan de capacidad puede sorprendernos y darnos las claves de como reducir costes, logrando dejar de vivir por encima de nuestras posibilidades de procesamiento o usuarios concurrentes.

Descartar el Cluster de VMware
Dependiendo de nuestras necesidades de disponibilidad es posible que las ventajas de tener un Hardware Virtual ya sean suficientes:
  • Escalabilidad, podremos cambiar el servicio a un Host más potente manteniendo la instalación, además de que podremos añadir CPUs y memoria en caliente.
  • Simplificación, llevando las migraciones a un simple vMotion sin corte de servicio.
  • Consolidación, es posible que existan varias instalaciones en la empresa, al unificarlas en un único Host y aprovecharnos de las características de gestión de recursos de ESX es posible que logremos reducir el coste de licenciamiento manteniendo la calidad del servicio.
Descartar el Cluster de Oracle (RAC)
Decantamos por la solución de Oracle sólo se justifica por motivos de disponibilidad, por lo que es muy posible que además estemos pagando licencias de RAC, lo que supone duplicar costes.

Hasta que VMware no publique Multiprocessor Fault Tolerance que pude ver en el VMworld, no existe alternativa a RAC. Pero es muy complicado que los clientes tengan el nivel de integración necesario con la base de datos para obtener todas sus ventajas, por lo que en la mayoría de ocasiones nos quedamos en que reiniciando los clientes volveremos a tener servicio.

Playing CardsSi es nuestro caso quizás disponer del  HA de los clusters ESXi sea suficiente. Ya que en caso de caída de uno de los Hosts, iniciará nuestra servicio en cualquier otro de los Host disponibles. Y por lo tanto podremos prescindir de las licencias de RAC.

En este punto es cuando un buen comercial de Oracle debería sacar un AS de la mangaRAC One Node, pero sinceramente no estoy seguro de que valga la pena...



Otras Aclaraciones
  • Tal y como he comentado, si el software esta instalado será necesario licenciarlo, por lo que tenemos que tener cuidado con los entornos de recuperación, incluso si se trata de replicación entre cabinas. Es necesario licenciar los equipos de recuperación como si fueran los de producción.
  • La regla de los 10 días tiene un gran hándicap, han de ser días alternos. Por lo que ya podéis asegurar un buen soporte hardware si queréis aprovecharos de estos días.
  • En uno de los grupos de discusión de VMworld del 2012 se comentaba que podíamos demostrar en que Hosts se habían ejecutado las instancias con logs. No hay nada como consultar un abogado para que te aclare que han de ser los auditores los que demuestren que incumples la licencia y no tu el que recopile logs para defenderte. Eso si, pueden pedirte ejecutar instrucciones especiales, programas o lo que necesiten.

Conclusión

Repito: lo que he escrito es una simple opinión y no tiene ninguna validez, lo mejor en caso de dudas es que consultéis a vuestros técnicos o consultores de confianza.

Dar las gracias al miembro de Oracle y al abogado que me han ayudado a completar mis dudas, por desgracia no he conseguido hablar con nadie de VMware =(

Pero si me preguntan, creo que la mejor opción es respetar las políticas de licenciamiento de los productos con los que elijamos trabajar. Pero no por evitar el conflictos, sino por que al tratarse de nuestras infraestructuras básicas deberíamos tratar de llevar la relación con estos fabricantes a otro nivel.

Esto a primera vista puede parecer que beneficia a Oracle, pero creo que sólo esta consiguiendo que muchos clientes se cuestionen uno de sus opciones estrella: Real Application Cluster. Y si a la amenaza de Multiprocessor FT le añadimos un problema de costes, es posible que la discusión esté cerrada más rápido de lo previsto.

¿Habéis decidido ya si vais a virtualizar vuestro Oracle?


Imagen: confusion
Imagen: Diversity quilt
Imagen: Playing Cards

6 comentarios:

Sebastián Greco dijo...

Hola Héctor!

Estupendo artículo!!! No esperaba menos de ti :) Abordas temas que me encanta que hayas podido discutir con un abogado. Lo de DRS...no encontré ningún "statement" de Oracle al respecto. Parece que hicieran como que "no existe". Sin lugar a dudas, un cluster exclusivo para Oracle es la solución definitiva.

Que los documentos sean de uso "educativo" me parece una tomadura de pelo por parte de Oracle...cuando lo vi inmediatamente pregunté a alguien de Oracle y me dijeron que lo único que tiene validez legal es el contrato que se firma con ellos. Por este motivo conseguí un contrato y es una de las cosas que todavía tengo en el to-do list por leer.

Con el paso del tiempo, me he encontrado en la situación que muchas veces la gente hace pruebas de Oracle en entornos virtualizados pero por temas de rendimiento no terminan de verlo claro. En lo personal, he conseguido rendimientos estupendos de Oracle virtualizados sobre vSphere y si alguien que se esté planteando virtualizar sus bases de datos está leyendo este comentario, mi sugerencia es que infraestructuras y DBAs deben trabajar juntos en cualquier proyecto de virtualización de Oracle. Son tantos y tan potentes los puntos de mejora que estos dos roles podrían (según el tamaño del cliente) ser sólo el principio.

Un abrazo Héctor! Muchas gracias por mencionarme en tu blog (creo que con esta ya van dos!)

En breve tendré que abordar un proyecto guapo guapo...igual te tengo que llamar para pregutnarte una o dos cosas de golden gates y data guards... :)
Sebas

Josep Ros - Ncora dijo...

Gran artículo Héctor!

Sigue así crack!

Un abrazo!

Antón Campos dijo...

FYI http://www.youtube.com/watch?v=dZ5Qip29Yt8

hmartinezlopez dijo...

Hola Sebas,

Si me lo permites te mencionaré en los que haga falta ;)

Comentar que tal y como explico, lo único que indica el contrato es que hay que licenciar "equipos con el software de oracle instalado o ejecutandose". Pero lo que me aclaró el abogado es que aunque el resto de documentos tengan la coletilla de "educacionales" ante un conflicto legal pueden llegar a utilizarse, aunque en ese caso no hay norma y dependerá del caso.

Sobre el rendimiento yo ya no tengo dudas, además obtener pruebas de que realmente va más lento que en un equipo físico es muy difícil.

Realizar una instalación con garantías también es complicado, y Oracle juega esa baza con las plantillas de Oracle VM. Pero espero aportar mi granito de arena en próximas entradas del blog.

Si puedo ayudar no dudes en llamar, aunque te aviso que tengo cierta predilección por DataGuard =)

hmartinezlopez dijo...

Gracias Josep!

hmartinezlopez dijo...

Gracias Antón,

Cuando apareció el vídeo se escribieron multitud de artículos certificando que en Oracle daban por validas las reglas de Host Affinity del DRS.

Pero ha quedado completamente desmentido, y hablando con el auditor de Oracle me quedó claro: no se trata de un tema técnico, sino de una postura comercial.

Si tienes un cluster, te reclamarán licencias para todos los Hosts del cluster.

También hubo quien preguntaba si cuando apareció en ESXi 5.1 la posibilidad de hacer vMotion sin storage compartido, sería necesario licenciar, no sólo los Hosts del cluster, sino todos los Hosts gestionados por el mismo vCenter.

No era más que un rumor, y muy a mi pesar tengo la impresión que lo único que conseguí fue levantar la libre... =)

Un saludo,

Héctor