No soy (ni de lejos) un conocedor del tema del Licenciamiento. Sin embargo, hace unos pocos días, me vi metido en unas batallas relacionadas con este tema, por lo que tuve que ponerme un poco las pilas. La verdad, que es un tema del que debemos estar todos más atentos de lo que solemos estar (y estoy generalizando), pues habitualmente el staff más técnico no suele estar al corriente de estos detalles, y son justo quienes más pueden ser de ayuda.
Antes de empezar, comentar que el tema del licenciamiento de Software, es como las tarifas de las operadoras de telefonía móvil: cambia con frecuencia (en formato e importe). Por ello, es muy importante revisar cuál es la situación actual de Licenciamiento de SQL Server, al margen, de que en el presente artículo introduzcamos los principales conceptos y términos generales.
Conceptos básicos de Licenciamiento de SQL Server
En resumidas cuentas, SQL Server puede licenciarse de dos formas diferentes:
- Licenciamiento por Procesador/Core. Se paga una licencia por cada Procesador/Core de la máquina, lo cual suele tener un importe diferente dependiendo de la edición de SQL Server (ej: Enterprise o Standard). Actualmente, con la llegada de SQL Server 2012, se realiza un Licenciamiento por Core, mientras que anteriormente se realizaba un Licenciamiento por Procesador. Importante este detalle, ya que existe procesadores que incluyen múltiples Cores. Es decir, si tenemos un servidor con 2 Procesadores Quad Cores, tendremos un total de 8 Cores repartidos en 2 Procesadores.
- Licenciamiento por CAL. En este caso, se paga un importe fijo por el Servidor (que dependerá de la edición - ej: Enterprise o Standard), y adicionalmente se paga un importe por cada Licencia de Cliente (CAL). No existen diferentes precios para las CAL, es decir, no existe un precio de CAL para Enterprise y otro para Standard. Si miramos para atrás, en algunas de las versiones anteriores de SQL Server se diferenciaba entre CALs para dispositivos y CALs para clientes (usuarios). Ahora hemos vuelto a un único tipo de CAL. Téngase en cuenta, que por ejemplo, una CAL de SQL Server 2008 nos dará derecho a conectarnos a SQL Server 2008 o cualquier versión anterior (ej: SQL Server 2005 ó SQL Server 2000), pero no tendremos derecho para conectarnos a versiones posteriores (ej: SQL Server 2008 R2 ó SQL Server 2012).
Este comportamiento es el mismo tanto para entornos físicos como virtuales. Sin embargo, actualmente en el caso de entornos virtuales, existe un caso especial: Si licenciamos por Core todos los Cores de un Host físico de Virtualización con Licencia Enterprise a través de Software Assurance, tenemos derecho a ejecutar en dicho Host infinitas máquinas virtuales con infinitas instancias de SQL Server, ya sean Enterprise o Standard. Esto implica, que algunas compañías se planteen montar un Cluster o Granja de VMWare o Hyper-V dedicada a virtualizar sólo y exclusivamente máquinas virtuales con SQL Server, con el objetivo de optimizar los costes de licenciamiento. Ojito con este tema, ya que podríamos pensar que en este caso, pues montamos siempre Enterprise y fuera: ERROR. El hecho de que ahora se Licencia de este modo, no garantiza que el año que viene sea también así. Por lo tanto, si lo que te hace falta son 15 SQL Server Enterprise y 20 SQL Server Standard, hazlo así, no sea que en un futuro cambie el modelo de Licenciamiento, y tú y tú CIO os llevéis un susto.
Otro tema peculiar es el de los Clusters. Si tenemos un Cluster con 2 Nodos, y una única instancia (Activo/Pasivo), tenemos la posibilidad de instanciar por Procesador/Core sólo uno de los Nodos. Sin embargo, si tenemos más de dos instancias de SQL Server (en al menos dos Grupos de Recursos), cambia el tema, ya que al ser posible que ambos Nodos puedas estar ejecutando SQL Server, entonces habrá que pagar Licencias de SQL Server para los 2 Nodos, en lugar de para uno sólo.
Estos son algunos de los principales conceptos sobre Licenciamiento de SQL Server, pero como ya comentaba antes, no soy un experto en el tema, y además, este tipo de cosas suelen cambiar con el tiempo y cabe la posibilidad de negociar con Microsoft algunas situaciones particulares.
A modo de referencia, a continuación se muestra el precio actual de SQL Server 2012.
¿Qué es el programa Software Assurance (SA) de Microsoft? ¿Cómo licencian las Grandes Cuentas?
Por lo que tengo entendido, el programa Software Assurance (SA) permite a las empresas la adquisición y mantenimiento de sus Licencias. Es decir, si deseamos licenciar un nuevo servidor SQL, podríamos adquirirlo a través de Software Assurance (SA). De este modo, con el paso de los años, tendremos la posibilidad de subir a la última versión de SQL Server, sin coste adicional, pues ya estamos pagando un mantenimiento (en cierto modo, podemos verlo como una subscripción). Visto de otro modo, al adquirir SQL Server a través de SA, podremos estar ejecutando cualquier versión de SQL Server.
Si nos ponemos la gorra del licenciamiento por CAL, recordemos que una CAL adquirida para una versión de SQL Server, sólo nos da derecho a conectarnos a esa versión o a versiones anteriores de SQL Server. Con Software Assurance (SA), estaremos siempre actualizados, y nuestras CALs nos permitirán conectarnos a cualquier versión de SQL Server. Interesante.
En el caso de las pequeñas empresas, podíamos adquirir en una determinada fecha un SQL Server Enterprise por CAL, para lo cual, tendríamos nuestro contrato. En una fecha posterior, podríamos adquirir otro SQL Server, en esta ocasión por Core y para la versión Estándar, para lo cual, tendríamos un nuevo contrato. Y así sucesivamente.
En el caso de las grandes empresas, la gran cantidad de adquisición y renovación de software que se produce a lo largo de un año, implica que el anterior procedimiento resulte poco práctica, por lo cual, en este caso suele realizarse una regularización anual. Es decir, las empresas pueden bajarse de la página de Microsoft Volume Licence el software, e instalarlo por doquier. No problem. Sin embargo, una vez al año, la empresa deberá declarar a Microsoft qué Licencias está consumiendo, para de este modo, regularizar su situación. Téngase en cuenta que Microsoft se reserva el derecho de poder realizar una Auditoría. Aquí se producen varias situaciones curiosas:
- Por un lado, las empresas tienden a declarar menos licencias de las que realmente están consumiendo. En ocasiones, Microsoft podría llegar a un acuerdo en esta situación, asumiendo, que los ingresos del total de Licencias adquiridas por el cliente (Windows, Office, Exchange, SQL Server, etc.) junto con el resto de servicios adquiridos a Microsoft (ej: Consultoría, Soporte Premier, etc.), le resulta rentable. Al final, simplemente se trata de alcanzar un acuerdo, un win/win, en el que las dos partes sientan que ganan. La vida es así. No se trata de un tema particular de Microsoft. Se trata de un tema general de negociación con Proveedores, sean de tecnología o no.
- Por otro lado, además de negociar el número y tipo de Licencias, también suele negociarse un descuento. Es decir, el precio de las Licencias es el mismo para todos en teoría, pero en la práctica, cada empresa negocia su descuento.
Además, en el caso de que Microsoft realice una auditoría, la información que se pueda obtener no siempre será tan clara como se podría esperar:
- Probablemente no se consiga auditar completamente toda la informática de la empresa cliente (ej: Sucursales geodistribuidas, DMZs, equipos que trabajan desconectados, etc.).
- En grandes empresas, dentro de la red se pueden encontrar activos pertenecientes a diferentes propietarios. Es decir, el Grupo de empresas CONTOSO GROUP tiene su propia infraestructura de red, en la cual hay elementos (ej: servidores) propiedad en exclusiva de alguna de las empresas del grupo (y no del Grupo como tal o matriz), aunque también hay otros elementos propiedad de la matriz. También podría haber activos pertenecientes a Partners, pues por ejemplo, algunos servidores podrían ser propiedad de la empresa que ofrece los servicios de Outsourcing. Esto se complica cuando hablamos de entornos tecnológicos que conviven en un ambiente de continuas adquisiciones, fusiones y ventas de empresas, dentro de una completa incertidumbre para el mantenimiento de los inventarios HW y SW.
- En el caso de una Aplicación Web, podríamos observar que sólo existe una conexión del servidor Web al SQL Server. Sin embargo, a través de esa única conexión, pueden estar trabajando múltiples usuarios, lo que hace que pueda no ser tan trivial medir cuantas licencias de usuario se están consumiendo. Esta situación se suele llamar multiplexación, y suele requerir licenciamiento por Procesador/Core.
- Una aplicación puede tener habitualmente 40 usuarios concurrentes, aunque con el paso de los meses, en algún momento puntual, se puedan producir picos de 500 o 600 usuarios concurrentes. ¿Se debe licenciar por 500 cuando se están consumiendo habitualmente 40?
- En el caso de un entorno tecnológico formado por multitud de instancias SQL Server, licenciadas de manera variopinta, con Multiplexación, entornos físicos y virtuales, equipos clientes que acceden a diferentes instancias de SQL Server, etc., es francamente difícil desde el punto de vista de una auditoría identificar claramente el número necesario de CALs.
Con todo esto, lo que quiero decir, es que al final todo se reduce a un careo, a una negociación, a un acuerdo en el cual ambas partes se encuentren satisfechas. Un win/win. A ninguna de las partes le va a interesar romper la baraja, porque sencillamente, no tiene ningún sentido. Como dije antes, es simplemente una situación típica de negociación con Proveedores, te vendan tecnología, vehículos de empresa, o cualquier otro activo o servicio.
¿Cómo configurar SQL Server 2000 conforme al modo de Licenciamiento adquirido?
Esta pregunta es buena. Sí señor.
En el caso de SQL Server 2000, durante la instalación de SQL Server 2000 es posible indicar el modo de licenciamiento y cuantas licencias han sido adquiridas. Una vez realizada la instalación de SQL Server 2000, podemos utilizar la herramienta SQL Server 2000 Licensing Setup, disponible en el Panel de Control. Esta herramienta nos muestra el modo de Licenciamiento que fue especificado durante la instalación, y las licencias que hay configuradas. Téngase en cuenta, que NO podremos cambiar el modo de Licenciamiento, aunque sí el número de Licencia. Una vez que hemos instalado, nos hemos “casado” con el modo de licenciamiento elegido.
Sin embargo, si por error adquirimos licencias de SQL Server 2000 en un formato (ej: por CAL) pero instalamos SQL Server 2000 en un modo de licenciamiento diferente (ej: por Procesador), ¿Qué hacemos?
Siendo sibaritas, deberíamos desinstalar y volver a instalar SQL Server 2000, lo cual, es una migración en toda regla, desde el punto de vista de riesgos, indisponibilidad del servicio durante dicha reinstalación, etc.
El caso, es que no existe ninguna limitación física en SQL Server 2000 relacionada con el modo de licenciamiento seleccionado durante la instalación. Es decir, instalemos SQL Server 2000 por CAL o por Procesador, nuestro SQL Server 2000 nos va a funcionar exactamente igual. Dónde quiero llegar, es que si tenemos adquiridas correctamente nuestras licencias, y simplemente, hemos elegido mal el modo de licenciamiento durante la instalación, tan sólo se trata de un error de forma, que probablemente podremos comentar con Microsoft, y poder estar en una situación legal de licenciamiento, sin necesidad de reinstalar. A esto, se le llama sensatez, y es que volvemos a lo de antes: se trata de una simple negociación con un Proveedor, en la que a ninguna de las dos partes le interesa romper la baraja, y menos por una tontería.
¿Cómo configurar SQL Server 2005 (y versiones posteriores) conforme al modo de Licenciamiento adquirido?
Buena pregunta, y fácil respuesta. NO SE PUEDE. No existe ninguna forma de configurar el modo de licenciamiento durante la instalación de SQL Server 2005 (o versiones posteriores). El número de serie viene ya hardcodeado en la ISO, y en ningún caso te pregunta el asistente de instalación. Tampoco existe ninguna opción entre los parámetros para realizar una instalación desatendida. Por supuesto, ya no existe en el Panel de Control una herramienta equivalente al SQL Server 2000 licensing Setup. Y por supuesto, las claves del registro de Windows que almacenaban la información del modo de licenciamiento y el número de licencias, simplemente, ya no existen.
El problema de esta situación, es que todo esto es bastante confuso, especialmente para quienes venían de SQL Server 2000, pues al empezar a realizar sus primeras instalaciones de SQL Server 2005, se volvían locos, al no ver forma de especificar durante la instalación el modo de licenciamiento ni el número de licencias, algo que sí podían hacer antes con SQL Server 2000.
Como conclusión, a partir de SQL Server 2005, no hay nada que configurar en SQL Server en relación con el modo de licenciamiento. Lo que importa, es el papelito, es decir, la licencia en sí. La ISO, es la misma independientemente del modo de licenciamiento adquirido.
¿Cómo comprobar en qué modo de Licenciamiento está instalado SQL Server?
Una pregunta con trampa, como ahora veremos.
En SQL Server 2000 podíamos comprobar el modo de licenciamiento desde el Panel de Control, como antes comentábamos, utilizando la herramienta SQL Server 2000 Licensing Setup del Panel de Control, la cual, desaparecería en versiones posteriores del producto, porque como también vimos, esto deja de funcionar así. Recordemos, que al final, esta herramienta se limita a leer/escribir un par del claves del Registro de Windows. Más simple que el mecanismo de un chupete.
Adicionalmente, en SQL Server 2000 podíamos ejecutar una SELECT utilizando la función SERVERPROPERTY para obtener los valores de LicenseType y NumLicenses. Al fin y al cabo, esta SELECT nos va a devolver la misma información del Registro de Windows que utiliza la herramienta SQL Server 2000 Licensing Setup del Panel de Control. Y aquí vuelve la confusión.
SELECT SERVERPROPERTY('LicenseType') AS [LicenseType]
SELECT SERVERPROPERTY('NumLicenses') AS [NumLicenses] |
A partir de SQL Server 2005, no existe ninguna herramienta para la gestión de licencias, ya que simplemente, no se especifica el modo de licenciamiento en la instalación. Sin embargo, a partir de SQL Server 2005 sí puede ejecutarse la anterior SELECT y utilizar la función SERVERPROPERTY para obtener los valores de LicenseType y NumLicenses, pero devolverán DISABLED y NULL respectivamente. Esto por desgracia ha creado aún más frustración, ya que en algunos casos, la existencia de dicha SELECT ha reforzado el suponer que es posible configurar de alguna manera el modo de licenciamiento de SQL Server, cuando esto no es así. Incluso, hay quien ha llegado a suponer que cuando esta SELECT devuelve DISABLED y NULL, lo que ocurre es que se está utilizando el modo de licenciamiento por Procesador, como configuración por defecto. Grave error. Esta SELECT, como muchas otras, se mantiene por motivos de compatibilidad hacia atrás, pero en SQL Server 2005 y versiones posteriores no tiene uso, ya que las claves del registro que utiliza como fuente, no son informadas por nadie, ni por el asistente de instalación de SQL Server, ni por ninguna otra herramienta.
Enlaces de interés y despedida
Antes de finalizar quería aprovechar para incluir algunos enlaces de interés, a modo de referencia, para quien pueda estar interesado en consultarlos:
Poco más por hoy. Como siempre, confío que la lectura resulte de interés.
