ACTUALIZADO. Si bien las ventajas de la virtualización son numerosas, garantizar un correcto licenciamiento en entornos virtualizados supone no solo un reto sino un riesgo alto de incumplimiento de licencia si no se logra.
Y en licenciamiento, los incumplimientos pueden medirse en millones de Euros además de suponer un riesgo legal y reputacional.
Es por ello que hay que extremar las precauciones:
- No solo en la instalación y uso de productos de software en entornos virtualizados ya que cada fabricante aplica reglas particulares
- Sino también en el diseño de la arquitectura antes de acometer un nuevo despliegue o realizar cambios de infraestructura de los data centers ya que los riesgos asociados en licenciamiento no solo se traducen en reclamaciones económicas desproporcionadas sino que pueden acarrear además consecuencias legales y reputacionales.
Así, aunque sean los mismos fabricantes los que faciliten, e incluso propongan, el uso de su software en escenarios de virtualización haciendo valer sus capacidades, lo cierto es que éste es uno de los principales factores para que se empleen a fondo en una auditoría en una auditoría de software, precisamente por el impacto potencial que puede tener un incumplimiento en estos entornos para fabricantes como Oracle, IBM, Microsoft, Software AG, etc.
En Evergreen Compliance somos ex-auditores de los fabricantes y de las Big Four, por lo que vamos a pasar a explicar en este artículo por qué el licenciamiento en estos entornos es un verdadero reto y qué hace de la virtualización «la joya de la corona» de las auditorías de software:
ESCENARIOS DE VIRTUALIZACIÓN REPRESENTATIVOS
En el caso de Oracle, si se desea aprovechar las ventajas de la virtualización ha de configurarse adecuadamente el particionamiento empleado en los sistemas, siendo los dos tipos principales Soft y Hard Partitioning. De esta forma, se estará en disposición de licenciar solo una parte del número total de cores existentes en un servidor físico o en un grupo de servidores.
Así, en Oracle cualquier tecnología que no esté expresamente reconocida como Hard Partitioning se considera Soft Partitioning. Éste último es el caso de Microsoft HyperV, Red Hat KVM, Citrix XenServer o VMware vSphere. En cambio, Oracle VM sí puede usarse como tecnología de Hard Partitioning si se cumplen ciertas condiciones. Asimismo, para licenciar productos de Oracle en entornos Cloud o en hardware como Exadatas han de considerarse también reglas especiales.
Otro referente en este ámbito lo constituye IBM, que exige el uso de la herramienta de medición IBM License Metric Tool (ILMT) o BigFix Inventory para poder trabajar en un escenario de virtualización o “Subcapacidad”. En caso contrario deberán licenciarse los servidores físicos completos en los cuales pueda ejecutarse potencialmente un producto contratado según la métrica PVU. No obstante, el uso de estas herramientas presenta en la práctica una serie de inconvenientes de diversa índole y el reconocimiento por parte de IBM (o de la Big Four de turno que utilice como auditor) de la sub-capacidad, no es evidente ni se hace por defecto.
En el caso de Microsoft, la virtualización constituye un especial reto para el licenciamiento de sus productos: en este ámbito, la suscripción de Software Assurance (SA) por parte del cliente va a ser un elemento crítico para su consideración.
CUÁL ES LA PERSPECTIVA DEL FABRICANTE EN EL LICENCIAMIENTO DE ENTORNOS VIRTUALIZADOS
Para que se entienda mejor la complejidad particular del licenciamiento en entornos virtualizados, es necesario ponerse primeramente en el lugar del fabricante y saber cuál es su perspectiva: Los fabricantes (Oracle, IBM, etc.), por defecto, únicamente permiten la instalación o uso de sus productos en servidores o entornos a los que no se les ha asignado previamente la debida licencia. Y esto es de sentido común.
El problema es que esta prerrogativa casa muy mal con las tecnologías de virtualización ya que precisamente una de sus razones de ser es permitir que las máquinas virtuales (MV) puedan moverse entre cores de un servidor o entre servidores de una granja para, por ejemplo, asegurar en todo momento la disponibilidad y continuidad del servicio.
Es por ello que los fabricantes exigen una suerte de «licenciamiento por potencia», es decir obligan a disponer de licencia no solo para los cores o servidores en los que se esté usando su producto sino también para todos aquellos cores o servidores en los que se pueda llegar a utilizar su producto como consecuencia de la tecnología de virtualización.
Los fabricantes exigen así un licenciamiento acumulativo y no alternativo. Es decir, obligan a licenciar los cores o servidores en los que se están utilizando ahora sus productos y además los cores o servidores en los que no se usan pero en los que potencialmente pueden llegar a usarse por el uso de la virtualización.
Para que se entienda mejor, es como si la policía nos multa no por la velocidad a la realmente vamos sino por la velocidad máxima a la que puede llegar nuestro coche a pesar de no alcanzarla en ningún momento.
CÓMO DE DEVASTADOR PUEDE SER UN ERROR EN EL LICENCIAMIENTO DE ENTORNOS VIRTUALIZADOS
Por ejemplo en el caso de Oracle, sus políticas pueden llevar a que la virtualización tenga como consecuencia un requerimiento casi exponencial de licencias para cubrir entornos en los que ni siquiera se está utilizando el producto.
En caso de usarse una tecnología calificada de soft partitioning (ej. VMware), Oracle considera que no es un medio apto para limitar el número de licencias necesarias en un servidor o cluster determinado y puede exigir el licenciamiento de cores de servidores o clusters a los que potencialmente pueda llegar la MV en la que se esté ejecutando el software: para saber más sobre la Oracle Partitioning Policy, pinche aquí.
Así, desde la versión 6.0 de vSphere ESXi como las MV pueden moverse entre diferentes vCenter, Oracle va a obligar por defecto que se licencien todos los cores de los hosts de todos los vCentes que, a su vez, manejen hosts con versiones ≥ESXi 5.1: es decir, se obliga a licenciar cientos cores donde no se usa Oracle simplemente por una única MV en un único host de un entorno virtualizado con vSphere ESXi ≥6.0.
Por otra parte, en los Engineered Systems (ej. Exadata), Oracle permite la sub-capacidad a través del uso de MVs en las llamadas «Trusted Partitions». El problema es que el incumplimiento de cualquiera de las condiciones requeridas va a propiciar que Oracle exija el licenciamiento de todos los cores del sistema independientemente del uso real: para saber más sobre Oracle Exadata Licensing pinche aquí.
Es fácil darse cuenta que, en este contexto, el riesgo puede ser de muchos millones de Euros y demoledor para el presupuesto en tecnología de cualquier organización:
- Puedes descargarte nuestro White Paper sobre licenciamiento de Oracle en VMware.
- Para conocer el impacto de la virtualización de licenciamiento en un ULA de Oracle, aquí y aquí.
CONCLUSIÓN
La mala comprensión de las políticas de licenciamiento en entornos virtualizados es el origen de las mayores reclamaciones por incumplimiento que hemos conocido en auditorías de software. Y lo sabemos, no solo por nuestra experiencia actual, sino porque somos ex-auditores de los fabricantes de software y de las Big Four.
A los fabricantes les encanta toparse con escenarios de virtualización durante sus auditorías de software porque saben que las posibilidades de que puedan identificar una situación de incumplimiento grave son altísimas.
En Evergreen Compliance sabemos qué buscan, dónde y para que y podemos ayudar a exprimir todas las posibilidades de la virtualización y de su inversión IT sin la contrapartida de un riesgo de incumplimiento en licenciamiento que se traduzca en millones.
Contacte hoy mismo con nosotros y conviértase en nuestro próximo caso de éxito conociendo cómo lo hemos conseguido en otros clientes.
