Llaga la versión LTS de Oracle 12c, bajo el nombre de 19c. Esta versión, ya disponible en versiones cloud y Exadata, pero no aún on-premise, trae una serie de cambios técnicos muy difundidos por Oracle, pero puede contener una bomba de profundidad a nivel de licenciamiento no confirmado aún de manera oficial, que es la desaparición de la tecnología RAC de Standard Edition, donde se encuentra disponible de serie históricamente.

Si no hay anuncio de Oracle, ¿por qué preocuparse?

Oracle no ha comunicado hasta ahora ningún cambio de licenciamiento al respecto. Cualquier propietario de licencias SE2 en RAC puede pensar que el ciclo de vida de su instalación está garantizado hasta 2025, fin del soporte de 12c. En 2017, Oracle ya había anunciado que 12.2.0.3 sería la versión final de 12c. Con posterioridad, 12.2.0.2 pasó a ser denominada 18c, y 12.2.0.3 19c.

b1.png

Este mapa se transformó en esto otro con la nueva nomenclatura:

Así, si consultamos por ejemplo la documentación de licenciamento más reciente previa a 19c, veremos que RAC forma parte de SE2 hasta 18c:

Disponibilidad de RAC por edición de BD en 18c
Disponibilidad de RAC por edición de BD en 18c

Sin duda, disponer de una opción activo-activo en la edición Standard hace que Oracle tenga ventajas importantes a nivel de alta disponibilidad sobre otras alternativas de coste similar (SQLServer), como de potencial coste más reducido (PostgreSQL / MySQL). Pero al consultar la misma información en la documentación de 19c, encontramos el cambio. SE2 ya no incluye RAC:

Cambio de disponibilidad de RAC por edición de BD en 19c
Cambio de disponibilidad de RAC por edición de BD en 19c

La involución de Standard Edition

Hasta la aparición de la versión 12.1.0.2, existían dos opciones «low cost» de la base de datos Oracle, Standard Edition One y Standard Edition, la segunda de ellas incluyendo RAC. SE1 permitía la ejecución en hasta dos sockets y SE en un máximo de 4 sin límite de cores en los dos casos. 12.1.0.2 trajo la desaparición de SE1 y SE, y la presentación de SE2. Actualizar las licencias a SE2 es necesario para poder actualizar el software y aplicar nuevos parches, con el correspondiente coste para los propietarios de licencias antiguas. SE2 impone un límite de 2 procesadores, algo que ya supuso un problema por ejemplo en clientes con RAC sobre servidores de 2 sockets. Si dispones de 4 licencias SE para un entorno de producción con un RAC de 2 nodos con 2 procesadores cada uno, no puedes actualizar a SE2 sin modificar previamente el hardware. Adicionalmente debes asumir el incremento de precio del soporte anual, siendo mayor el impacto económico en clientes SE1. Además del nuevo límite de procesadores reducido, desde 12.1.0.2 SE2 tiene hard-coded una restricción de paralelismo para toda la instancia de un máximo de 16 threads, limitando con ello la escalabilidad. El resumen es un mayor coste de licenciamiento y de soporte a cambio de restringir la capacidad de procesado.

Con 19c, es posible que quienes han evolucionado o adquirido nuevas licencias para SE2 con la intención de utilizar RAC, pueden perder a corto plazo parte del valor de esa inversión, la alta disponibilidad y escalabilidad RAC, ya que 18c tiene como fecha de caducidad el primer trimestre de 2021. A partir de ese momento, no habría nuevas actualizaciones para ese RAC. Para el movimiento a 19c sería necesario un cambio de arquitectura y moverse a single instance (presumiblemente al mismo precio).

Así, si hoy instalamos la última versión disponible on-premise (18c) con RAC y compramos nuevas licencias para este entorno, el ciclo de vida de la solución será de menos de 2 años, pudiento estar comprando una tecnología que dejará de ser viable antes de completar el tiempo previsto de amortización.

¿Qué alternativas dará Oracle?

Una posibilidad parece ser que será el reconocimiento de licencias SE2 como opción BYOL (Bring Your Own Licenses) de la Autonomous Database con una conversión que podría ser de 4OCPUs por cada socket SE2 licenciado. De ser así, Oracle estaría reforzando la presión sobre sus clientes para el movimiento a cloud para competir con AWS y Azure principalmente.

La nube como estrategia

La estrategia de Oracle es clara, apostar por la nube, concretamente por la suya. Así, estos posibles cambios y conversiones de licencias encajarían en esa estrategia de ganar masa de clientes en los servicios cloud.

La nube es a día de hoy una gran parte del presente, y lo será todavía más en el futuro, pero en este momento siguen existiendo reticencias y limitaciones técnicas a la hora de moverse a este tipo de servicios. En el caso de una base de datos, cambiar de modelo implicará cambios adicionales en forma de rendimiento y mayores latencias, especialmente si mantenemos en remoto clientes y servidores de aplicaciones, que puede no ser aceptable para todo el mundo.
La estrategia de movimiento a la nube choca también con la actual predisposición de muchos clientes. En el webimar de presentación a partners de las nuevas funcionalidades 19c al que pude asistir, una de las encuestas hechas por Oracle era qué sobre el tipo de despliegues en los que están interesados actualmente los clientes de los partners que asistíamos. El 18% de los asistentes marcaron la opción cloud, 36% on-premise, y el 47% soluciones híbridas, con todo lo ambíguo que este concepto puede llegar a ser. Se trata de una encuesta poco fiable a nivel estadístico, y ni siquiera conozco el número de asistentes, pero me encaja en el día a día de nuestros clientes a día de hoy. Este hecho me hace pensar sobre cuánto tiene de solución (mucho sin duda) y cuánto de márketing los servicios cloud, y qué cambios surgen con el fin de dar servicio a tus clientes, y cuales lo hacen para marcar el camino que prefieres que sigan.

En la visión cloud de Oracle, es importante tener en cuenta que RAC no tiene soporte en ningunha plataforma cloud que no sea la de Oracle, otra limitación adicional a la libertad de elección de los clientes, de manera similar a lo que ocurrió con VMWare y el soporte de virtualización y reconovimiento de particionado de CPUs, batalla claramente perdida por Oracle.

Próximos pasos

En este momento, las cosas parecen claras, pero no están confirmadas, y sería una muy buena noticia descubrir que esta interpretación no es la correcta y que podremos seguir usando RAC en 19c SE2, pero hay varias dudas a resolver a corto plazo:

  • Respuesta oficial de Oracle. ¿Es un error lo que vemos en la documentación y tendremos RAC en 19c? En Arumel estamos esperando confirmación a nivel comercial de Oracle España.
  • Disponibilidad de 19c on-premise. Esto permitirá resolver al menos la duda de si el instalador de SE2 permite desplegar RAC. En el momento de escribir esta entrada, sólo está disponible 19c en cloud y Exadata.
  • Soporte RAC para la familia 12c. En caso de desaparecer, ¿qué ocurre con aquellos que invirtieron en licencias para una instalación RAC sobre 12c con un ciclo de vida que debería finalizar en 2026? ¿Morirá esta inversión on-premise 5 años antesde lo previsto?
  • Con las restricciones que vemos estos años, ¿cuál es el futuro de SE2? ¿Apostamos por Oracle en cliente «no Enterprise» o pasa a ser una opción de riesgo de ruptura de baraja por parte del proveedor cuando su estrategia no encaje con la del tipo de cliente de sus productos?



A %d blogueros les gusta esto: