Hola amigos,
En esta nueva entrada hablaremos sobre uno de los aspectos que más confusión crea a la hora de virtualizar Oracle sobre vSphere, el licenciamiento.
Antes de ir al lío, permitidme ahorrar la lectura del artículo entero a quien simplemente quiera respuesta a la eterna pregunta:
¿Tengo que licenciar todos los procesadores físicos del host si únicamente presento 1 vCPU a la VM con Oracle?
La respuesta rápida es “SÍ”.
La respuesta un poco más larga es “Sí, para todos los servidores en los que se vaya a ejecutar Oracle y en caso de utilizar un modelo de licenciamiento por procesador y no por usuario además de utilizar una tecnología de virtualización distinta a Oracle VM configurado de la siguiente forma:
http://www.oracle.com/technetwork/server-storage/vm/ovm-hardpart-168217.pdf
Veréis que en el documento antes mencionado se habla de la capacidad de ofrecer “hard partitioning” con Oracle VM gracias a su funcionalidad de “pinning” que a primera vista y sin conocer en profundidad su funcionamiento, se parece mucho (por no decir que es lo mismo) a las funcionalidades conseguidas con la afinidad de CPU de VMware. Dicho esto, Oracle tilda su tecnología como “hard partitioning” y la de VMware como “soft partitioning”. Soft partitioning no ofrece ninguna ventaja a efectos de licenciamiento con Oracle y hard partitioning sí.
Eso sí, recordad que si bien Oracle VM permite realizar “hard partitioning”, lo hace bajo ciertas condiciones:
Live migration of CPU pinned virtual machines to another Oracle VM Server is not permitted under the terms of the hard partitioning license. Consequently, for Oracle VM 3, DRS (Distributed Resource Scheduler) and DPM (Distributed Power Management) policies should not be enabled for server pools containing CPU pinned guests.
Sobre el licenciamiento:
- ¿Qué dice VMware al respecto?
- Existe un tipo de licenciamiento llamado “Named User Plus”. Para este tipo de licenciamiento no hay ningún impacto en utilizar vSphere.
http://www.oracle.com/us/corporate/pricing/databaselicensing-070584.pdf
Este licenciamiento lo utilicé una única vez en la que necesité licenciar Oracle para albergar únicamente la base de datos del propio vCenter y Update Manager y en la que se utilizaría un único usuario para trabajar con las bases de datos tanto de forma directa como indirecta. Opción mucho más económica que otro modelo de licenciamiento para este escenario.
- La mayoría de las tecnologías de Oracle se licencian por socket físico o core sobre el cual se “instala” o ejecuta. Este es el tipo de licenciamiento sobre el cual se discute generalmente. Lo de “instala” lo pongo entre comillas porque es la definición que utiliza el propio Oracle y la quería dejar reflejada, aunque desconozco y dudo que exista la posibilidad de “instalar” software en un procesador…
Sobre este tipo de licenciamiento, estas son algunas características:
- La licencia no toma en cuenta la ubicación de la base de datos sino en qué procesador se ejecute (importante tenerlo presente para escenarios de recuperación ante desastres como veremos más adelante).
- En un host virtualizado con vSphere, se deben licenciar todos los procesadores y cores (en este caso no hay opción de licenciamiento de tipo “hard-partitioned”).
http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf
- Se pueden ejecutar un número ilimitado de workloads virtuales en un host totalmente licenciado.
- Oracle no tiene ninguna política específica declarada en cuanto mecanismos de VMware clustering o DRS Host Affinity.
- En líneas generales, todos los nodos que en algún momento ejecuten cargas de Oracle, han de estar totalmente licenciados. Esto incluye HA, FT, operaciones de vMotion manuales o por DRS, migraciones “frías”, etc.
Digo lo de “en líneas generales” porque existen ciertas excepciones.
| Funcionalidad VMware | Requerimiento de licencia en primario | Requerimiento de licencia en secundario |
|
HA |
SÍ |
Con storage compartido en el mismo site, NO hasta 10 días por año |
|
vMotion |
SÍ |
NO hasta 10 días por año |
|
Fault Tolerance |
SÍ |
SÍ |
|
SRM |
SÍ |
SÍ, si se replican los ejecutables de Oracle. NO si se utiliza backup. |
Para obtener información más exhaustiva, seguir el siguiente link:
http://www.oracle.com/us/corporate/pricing/sig-070616.pdf
En la página 20 está lo de los 10 días.
Adicionalmente a lo ya comentado, se pueden ver los registros para comprobar los movimientos de las VMs.
- vCenter genera y mantiene logs (hostd.log y vmware.log) de migración que pueden ser usados para llevar un control interno y/o externo (por ejemplo en caso de una auditoría).
- vCenter cuenta con APIs para que se puedan integrar herramientas de terceros que controlen el “compliance” del licenciamiento.
Sobre las ediciones:
Poco podré decir que no diga el propio Oracle en su página Web.
http://www.oracle.com/us/products/database/enterprise-edition/comparisons/index.html
Sin embargo me gustaría destacar algunas cosas:
- Oracle Database Standard Edition:
- Se licencia por socket sin tener en cuenta la cantidad de cores.
- “Procesador” equivale a “socket”.
La cantidad de sockets habilitados en la BIOS, equivale al número de “procesadores” que hay que licenciar.- La cantidad de sockets ocupados, equivale al número de “procesadores” que hay que licenciar.
- Cada tipo de licencia de Standard Edition está limitado a una capacidad máxima de sockets. A efectos de esta limitación, sí cuentan los sockets vacíos o deshabilitados.
- Ejecuta el mismo motor de base de datos que Oracle Database Enterprise Edition.
- Existen dos opciones:
- Oracle Database Standard Edition One (SE-1).
- 1/16 parte del precio de la Enterprise Edition (aproximadamente).
- Máximo de 2 sockets.
- Oracle Database Standard Edition (SE) (mayor número de funcionalidades y mejor escalabilidad).
- Máximo de 4 sockets.
- Incluye Oracle RAC (limitado a clústers de hasta 4 sockets).
- Oracle Database Standard Edition One (SE-1).
En cuanto a Oracle XE, explico en una entrada de mi blog personal de la VMware Community porqué no es válido para ejecutar sobre él, las bases de datos de vCenter ni siquiera para entornos de prueba/laboratorio.
Reducción del número de licencias en entornos de recuperación ante desastres
En el siguiente diagrama se enseña un modelo de Disaster Recovery utilizando VMware Site Recovery Manager y en el que se intenta evitar “sobre-licenciar” la infraestructura. Por lo menos hasta que ocurra un desastre y haya que hacer un failover.
La idea es simple:
1) Replicación asíncrona de las bases de datos (no de los ejecutables).
Con esto tendremos a resguardo y disponible la información.
2) Pruebas de recuperación de las copias en los hosts licenciados en el site primario.
Simplemente para verificar que lo que estamos copiando, es recuperable. En este escenario las pruebas se realizan utilizando la WAN que nos une al site secundario, con el impacto correspondiente en el rendimiento. Pero bueno, se trata de probar la fiabilidad del sistema y el rendimiento no es un factor relevante en este tipo de pruebas.
3) En caso de tener que realizar un failover, habrá que licenciar los nodos en el site secundario según se vayan a utilizar.
Resumiendo:
Existen varias formas de licenciar y varias ediciones de Oracle siendo el licenciamiento por socket el más debatido.
VM 3 de Oracle es el único hipervisor que permite no tener que licenciar todos los procesadores físicos sino los procesadores virtuales que la máquina virtual que ejecuta Oracle utiliza. Existen ciertas condiciones que se deben cumplir para que esto sea así.
Existen formas de reducir el número de licencias necesarias incluso con VMware, si se diseña el entorno aprovechando al máximo las capacidades de las soluciones de VMware y conociendo los modelos de licenciamiento de ambos fabricantes.
Cualquier host de VMware ha de contar con todos sus procesadores físicos cubiertos por el licenciamiento de Oracle. Esto también permite que se puedan crear n máquinas virtuales que ejecuten Oracle sobre ese host.
Espero haber aclarado algunas cosas y haber dejado en un post, si bien no toda la información al respecto, una guía bastante completa a efectos de licenciamiento de Oracle sobre vSphere y en la cual existen los links oficiales a la información que no incluí en este post.
La multa por violar el acuerdo de licenciamiento puede llegar a ser extremadamente alta (he visto ejemplos que hablaban de millones de dólares…), tanto en entornos virtualizados como físicos. Cualquier precaución está más que justificada y cualquier pregunta debería ser más que bienvenida tanto por parte de fabricantes como por parte de sus canales de distribución. Os animo a que preguntéis siempre todas vuestras dudas y agradeceré cualquier información que podáis añadir a lo ya escrito en este post J
Si os gustó el post, por favor compartid el link en vuestras redes sociales. Tal vez también le sea de utilidad a otros y así también nos estaréis echando un cable en dar a conocer este blog!
Saludos y gracias por leernos!!!
