Oracle no está soportado sobre VMWare

FALSO. Oracle no certifica su base de datos sobre VMWare, y las soluciones que da están orientadas al SO y equipo físico y no a nivel de virtualización. Oracle dará siempre asistencia a sus productos desplegados sobre VMWare, siempre que se pueda demostrar que no es un problema asociado a la ejecución en VMWare. Esto quiere decir que en un momento determinado Oracle podría no continuar investigando un SR si considera que debe ser escalado a VMWare, algo que a día de hoy, y tras la apertura de numerososcasos sobre plataformas virtuales VMWare, no me ha ocurrido, incluso en aquellos casos que han acabado con la creación de un nuevo bug request interno.

En la documentación de Oracle sí hay una nota explícita a que no se admitirán SRs para BDs RAC en versiones anteriores a la 11.2.0.2, pero desconozco si esta condición es aplicada de manera estricta. En 2015, en este WhitePaper, VMWare indica que hasta ese momento nunca recibió una incidencia relacionada con la BD Oracle en la que vSphere fuese el causante:

 

Para añadir un disco en caliente en RAC es necesario apagar las VMs

FALSO.Añadir nuevos discos ASM es completamente posible sin parada de servidor de ningún tipo. Cuando usamos un datastore para crear los discos ASM, en realidad estamos utilizando un sistema de ficheros VMFS que por defecto deshabilita el acceso desde múltiples máquinas virtuales a los discos vmdk. La capa de almacenamiento ASM es consciente de la existencia de un clúster de almacenamiento en una configuración RAC y gestiona la concurrencia de acceso a través de múltiples nodos del clúster a los mismos ficheros, no dependiendo de tecnologías de SO o del protocolo SCSI para su coordinación. Para este tipo de aplicaciones cluster-aware, VMWare permite deshabilitar esta restricción, activando el flag multi-writer en la configuración del disco.

En la versión ESXi 5.5 o bug VMWare 2078540 provocaba que el flag multi-writer se deshabilitase cuando un disco era añadido a una arrancada, fallando la adición de nuevos discos ASM e impidiendo que éstos fuesen añadidos en caliente. Este problema fue solucionado en la versión ESXi 5.5 P02 build -1892794, por lo que versiones posteriores no tienen esta limitación. En caso de estar trabajando con una versión  afectada por este bug, la solución de contingencia es efectivamente el apagado de las máquinas antes de añadir el disco.

 

Si uso RAC sobre VMWare no puedo hacer snapshots de las VMs

FALSO. Es habitual encontrarse ante clientes que temen o sufren este problema, derivado de una incorrecta configuración de las MVs RAC a nivel de VMWare. Es cierto que la utilización de la opción multi-writer limita las funcionalidades disponibles sobre los discos. Podemos ver estas limitaciones en la tabla de soporte funcionalen la web de VMWare.

En mi opinión por experiencia con sysadmin y administradores VMWare, resulta confuso encontrarse en la matriz con que los snapshots no están soportados, lo que es cierto, pero desde el punto de vista Oracle, lo que nos interesa realmente es ver que sí hay soporte para hacer snapshots de VMs con discos intependientes y persistentes, disponible desde vSphere 5.1u2. Si seguimos la documentación de VMWare Oracle Databases on VMware RAC Deployment Guide, nuestro RAC debe contar con:

  • Controladora Paravirtual independente de la de los discos de sistema (SO y software Oracle) para los discos compartidos (ASM).
  • Thick Provision Eager Zeroed. El disco será generado con su tamaño real y llenado con valores cero. Se trata de un proceso de creación de disco más lento que empleando otras opciones como thin-provisioning.
  • Multi-Writer.
  • Independent si usamos VMFS (independent-persistent si usamos RDM).

Vemos estas configuraciones en varias capturas del mencionado documento de RAC para VMWare:

Discos virtuales compartidos para ASM asociados a controladoras paravirtuales. Existen dos controladoras por la limitación de número de LUNs máximo al que cada controladora puede dar servicio.

Los discos compartidos para ASM tienen habilitado el flag multi-writer

Configuración independiente y con Thick Provision Eager Zeroed cuando creamos discos ASM sobre VMFS. En caso de emplear RDM, los discos deben ser Independent-Persistent

 

No puedo usar Veeam Backup en máquinas VMWare con RAC

FALSO desde la versión 5.1 de vSphere. El motivo es similar al del anterior punto. Debemos tener corectamente configurados las controladoras y los discos, tanto los de ASM con los de sistema. Con esta configuración, podremos hacer snapshots de la VM quedando excluídos los discos ASM, pero la copia Veeam (o tecnología equivalente) funcionará, dependiendo de RMAN la recuperación de la BD si fuese necesario.

 

En un clúster VMWare debo licenciar todos los procesadores físicos

MUY DISCUTIBLE. A nivel comercial y de auditoría (LMS), no habrá duda, y Oracle venderá y exigirá que todos los procesadores del clúster VMWare estén licenciados para su software. Esto puede ser especialmente grave cuando empleamos versiones Standard, ya que Oracle podría reclamar el pago de una licencia Enterprise por la limitación del número máximo de sockets de SE (4) o de SE2 (2).

VMWare mantiene un documento denominado Understanding Oracle Certification, Support and Licensing for VMware Environments en el que defiende la posibilidad de licenciar sus clúster de manera parcial mediante el uso de una configuración DRS que limite el movimiento de máquinas, y con el mantenimiento de un registro de movimiento entre nodos que permita justificar los procesadores sobre los que el software Oracle se ha podido usar. Esta propuessta de VMWare fue respaldada en el año 2012 por Richard Garsthagen, Director de Desenvolvemento de Negocio Cloud de Oracle. Enenero de 2017, VMWare publica en su blog oficial esta nota en la que es mucho más clara la argumentación de licenciamiento y donde se hace referencia explícita a la configuración a utilizar y a los condicionantes de los acuerdos de licenciamiento de Oracle, específicamente en lo recogido en el OLSA y en el OMA. En este documento, VMWare es contundente en la afirmación de que es posible licenciar un subconjunt de servidores Oracle cumpliendo el acuerdo de licenciamiento que el cliente debe firmar, simplemente mediante una adecuada configuración de DRS, y con el uso de la herramienta VMWare LogInsight. Los logs de VMWare determinarán la cantidad de procesadores físicos empleados.

Oracle considera VMWare como una tecnología soft partitioning, donde la limitación de recursos que una partición (máquina virtual en esete caso), es hecha a través de los recursos del SO, entre ellos la limitación de CPUs en las que el software es ejecutado. Soft partitioning no es aceptado por Oracle para restringir los procesadores a licenciar. Técnicamente, la idea es que soft partitioning non nos permite diferenciar o limitar los cores y procesadores que una VM utilizará. No hay ninguna configuración ni tecnología VMWare que Oracle (a diferencia de lo que hace con OVM), reconozca para limitar el número de cores a licenciar.

Entonces, ¿qué ocurre si nunca muevo mi máquina virtual dentro del clúster VMWare? Podría deshabilitar vMotion o limitar con DRS los ESX en los que arrancar. En este caso, ¿bajo qué concepto es necesario licenciar un hardware que nunca ejecutará software Oracle? La respuesta es simplemente la previsión o posibilidad de hacerlo en algún momento. La argumentación de VMWare en este sentido es más razonable que la de Oracle, y lo sintetiza perfectamente la expresión “Galaxy Licensing” que implicaría la interpretación de licenciamiento Oracle teniendo en cuentas las capacidades funcionales actuales de VMWare y específicamente de vMotion, ya que vMotion no restringe el movimiento de máquinas a un vCenter como Oracle sí interpreta. Entonces, VMWare dice, ¿por qué no ir más allá y licenciar todo aquello que esté al alcance de vMotion?.

 

Con Oracle VM puedo restringir los cores a licenciar

CIERTO.Oracle acepta la configuración de pinning de CPU en Oracle VM como tecnología hard partitioning. Por lo tanto es posible licenciar solo los cores o sockets que están en uso por las MVs utilizadas por Oracle. Existe una restricción con esta configuración, y es que Oracle no acepta para Standard Edition 2 ninguna tecnología hard partitioning, incluyerndo OVM, si se utiliza en servidors con una capacidad superior a 2 sockets. Esto en realidad nos deja una nueva categoría que podríamos denominar “intermediate-partitioning” (expresión inventada) ya que la limitación es puramente conceptual, rompiendo un poco más la coherencia de los conceptos soft y hard partitioning.

A %d blogueros les gusta esto: