Optimización de costos de SQL en la nube de AWS

Por: Caio Ribeiro César, Phil Ekins, Javier Gálvez

Los clientes llevan más de 12 años ejecutando cargas de trabajo de Microsoft en AWS, más que cualquier otro proveedor de nube. Los clientes eligen AWS porque tenemos más experiencia con las aplicaciones de Microsoft en la nube y ofrecemos la mejor plataforma para Windows Server y SQL Server en las siguientes áreas: mayor rendimiento y confiabilidad, mayor seguridad, servicios de identidad, soporte de migración, mas características amplias y profundas, menor costo total de propiedad y opciones de licenciamiento flexibles. AWS soporta todo lo que usted necesita para crear y ejecutar aplicaciones de Windows, incluidos Active Directory, .NET, Microsoft SQL Server, servicio de escritorios Windows y todas las versiones compatibles de Windows Server. Con nuestra experiencia comprobada, podemos ayudar a los clientes a migrar, cambiar, refactorizar o incluso modernizar sus cargas de trabajo de Windows.

En esta publicación, analizaremos algunas estrategias de reducción de costos para SQL en la nube de AWS.

1. Utilizando AWS OLA

¿Cómo puedo empezar con AWS OLA? Usted puede trabajar con alguno de nuestros partners como por ejemplo Cloudmize, Cloudchomp o incluso hablando directamente con AWS a través de su gerente de cuentas. Realizaremos una evaluación detallada, recopilando los datos de su infraestructura.

OLA proporcionará un entendimiento de cómo se están utilizando sus recursos en el origen así como las licencias y recursos que se estén utilizando actualmente. Estos datos nos proporcionaran una vision precisa de cómo reducir costos en el entorno de destino. ¿Pero cómo? A partir de la evaluación, podemos obtener datos de rendimiento de la infraestructura y comprender si existe un sobre-aprovisionamiento o, mejor aún, aprovisionamiento excesivo de licencias.

2. Eligiendo el tipo de instancia correcto en AWS

Siempre necesitamos alinear la carga de trabajo con el tipo correcto de instancia requerida. Las instancias amarillas en la siguiente lista están también disponibles para ser utilizadas por nuestro servicio Relational Database Service (Amazon RDS), así como las instancias que están subrayadas también se pueden utilizar bajo el esquema de alojamiento dedicado (Dedicated Hosts). Para aquellas cargas de trabajo SQL que utilizan mayormente memoria, se podrían utilizar instancias con memoria optimizada, como r5 o x1, y generalmente son las instancias apropiadas para esos casos. Si su carga de trabajo de SQL utiliza mayormente CPU, ofrecemos instancias que son especializadas en procesamiento intensivo, como la familia c5.

Al elegir el tamaño de proceso adecuado para su carga de trabajo, significa que está obteniendo la proporción perfecta de memoria y CPU y no está sobre aprovisionando los recursos, y por ende también bajarían los costos de licencia.

Además, contamos con instancias del tipo R5b que nos dan performance de IOPS más altas y, en consecuencia, mas ancho de banda disponible. Debido a que la mayoría de los entornos SQL requieren de valores altos de IOPS, es posible que necesite menos núcleos (vCPU) así como mejores rendimiento de memoria y disco, por lo que se necesitan menos licencias.

3. Utilice CPU Optimization

Si miramos hacia atrás en el mundo onpremises, al construir SQL Server, pediremos un servidor con mucha memoria (digamos 4 TB de memoria) para un entorno SQL clásico. En ese momento, por lo general no necesitábamos un numero elevado de CPU porque dependíamos de la memoria.

Hoy en día puede obtener el mismo servidor en la nube, digamos 4 TB de memoria, que viene con mucha potencia de CPU, lo que aumentaría el costo de licencia, pero podemos reducir este costo de licencia con la opción de optimización de CPU. Esto significa que podemos tomar una instancia con mucha memoria (como el r5 o x1 mencionado anteriormente) y luego habilitar la función de optimización de CPU para la instancia elegida, utilizando menos núcleos de CPU y pagando menos licencias SQL, lo que reducirá los costos de la base de datos.

*Estos son solo ejemplos, recordando que hay un requisito mínimo de 4 núcleos para licencias en el servidor SQL, lo que significa que puede escalar su entorno de vez en cuando y probar qué rendimiento es mejor, y asegurarse que no compre «licencias de mas».

4. BYOL (traiga su propia licencia) vs Licencia Incluida

Como se ha dado cuenta en este momento, entender las reglas de licenciamiento es fundamental para reducir el costo de los entornos de SQL Server. Los clientes utilizan BYOL (Bring Your Own Licence) por una serie de razones, como poseer de antemano las licencias en el entorno de origen, aprovechar el uso de sus licencias no utilizadas en entornos híbridos, usar los beneficios de la garantía de software, como no pagar por nodos pasivos en escenarios de alta disponibilidad o recuperación ante desastres con software assurance.

Por otro lado, los clientes también optan por el modelo de «licencia incluida», ya que esto evita la complejidad de los requisitos de licencia de SQL Server, como por ejemplo la regla high water mark, por consiguiente, estos clientes pueden licenciar su entorno mensualmente, dando la posibilidad de apagar los servidores cuando el proyecto haya sido completado, pagando sólo por los recursos y licencias que se hayan utilizado en ese periodo de tiempo, además de eliminar la necesidad de acuerdos de licenciamiento con Microsoft, como el Enterprise Agreement y Server and Cloud Enrollment (SCE). Además de esto, muchas veces no sabemos cuantos recursos va a necesitar servidor, por lo que la licencia incluida le ayuda a no tener un compromiso de antemano hasta que realmente comprendamos los recursos necesarios para la carga de trabajo a ejecutar.

No hay magia en esto. La combinación de estas dos ofertas le hará más dinámico y adaptable a los cambios en su entorno. Lo más importante es simplemente entender cuándo elegir una de las opciones disponibles.

Recuerde: BYOL solo se aplica a EC2, mientras que la Licencia Incluida se aplica tanto a EC2 como a RDS.

5. Consolidación de cargas de trabajo SQL

¿Recuerdas cuando mencionamos que necesitamos licencias de cuatro núcleos al menos como requisito para SQL? Esto significa que es una buena idea consolidar cargas de trabajo de SQL que son pequeñas en instancia más grandes.

Lo que significa que puedo tomar instancias por debajo del tamaño mínimo de cuatro núcleos y combinarlas en una sola instancia.

En el ejemplo siguiente, tenemos cuatro instancias SQL, cada una fue dimensionada con un requerimiento de 2 vCPU para un total de 8 vCPU, pero esto requiere 16 núcleos licenciados. Al consolidar estas cuatro instancias en dos instancias más grandes, hemos eliminado el 50% del costo de las licencias.

6. Considere como opción «step-down» desde un SQL Enterprise a un SQL Standard

Un step-down desde la edición Enterprise a Standard reducirá los costos de licencias, así como los costos anuales de Software Assurance. A partir de SP1 2016, muchas características exclusivas de Enterprise también están disponibles para la versión estándar. Esto significa que usted podría estar ejecutando un entorno que ya no requiere la edición Enterprise.

Recientemente, por ejemplo, la versión SQL 2019, la opción de Cifrado Transparente de Datos (TDE) se ha convertido en una opción disponible en la edición estándar. En este punto, la pregunta que tenemos que hacernos es, ¿realmente necesito la Enterprise Edition? Si usted está utilizando read replica, reindexación en línea, si sus servidores utilizan más de 128 GB de RAM para SQL, entonces sí la necesita. Comprender el entorno y combinar la edición de licencia adecuada es importante.

Otro ejemplo es la arquitectura de alta disponibilidad para estas versiones. Para la edición Enterprise, como se ilustra a continuación, utilizamos Always On AG con réplicas primarias, pasivas y de lectura comparado con la versión Standard donde podemos implementar el mismo modelo de alta disponibilidad mediante clústeres de failover de Windows Server utilizando nuestro servicio de FSx que nos brinda un almacenamiento compartido.

Antes de realizar el downgrade de versión, tenemos que tener en cuenta algunas cosas, por ejemplo, si se encuentra en vigencia su Contrato Enterprise y/o si usted ya ha adquirido las licencias con derechos de uso perpetuo.

7. Utilizando Dedicated Host (DHS)

Si usted dispone de licencias de sistema operativo Windows y desea traer estas licencias de software de Microsoft que no tengan las ventajas de Software Assurance o Movilidad de licencias, podría hacerlo, siempre y cuando las licencias hallan sido adquiridas antes del 1 de octubre de 2019 o se agreguen como true-up bajo una inscripción Enterprise activa que entró en vigor antes del 1 de octubre de 2019. Los Dedicated Host de EC2 se recomiendan para clientes que traigan SQL Server sin un Software Assurance activo.

Para que SQL Server sin Software Assurance activo pueda ser elegible para BYOL en EC2 Dedicated Host, la versión debe ser SQL Server 2017 o una versión anterior y la licencia debió haberse adquirido a Microsoft antes del 1 de octubre de 2019 o adquirido como un true-up en virtud de un acuerdo empresarial activo que entró en vigor antes del 01/10/2019.

Lo que significa que, si la licencia no cumple con estos requisitos, los términos de licencia de Microsoft no permitirán BYOL y entonces debemos considerar la opción de  licencia RDS SQL o EC2 incluida. Los hosts dedicados pueden proporcionar importantes beneficios de costos y permitir a los clientes controlar la ubicación de sus instancias y licencias en un host físicamente dedicado a su uso.

Para los sistemas locales que utilizan intensamente de la virtualización ilimitada de Windows/SQL Server y desean seguir utilizando este tipo de licencia, DH es la forma de hacerlo. Si utiliza mucho el hipervisor y concede licencias SQL por núcleos de CPU físicos, un modelo de shared tenancy se vuelve demasiado caro para las cargas de trabajo SQL, por lo que DH puede ser una mejor opción.

Es importante tener en cuenta que no todos los clientes licencian SQL en el modelo de «core licensing».

Los clientes pueden licenciar el Host Dedicado completo con SQL Enterprise Server+ CAL, pero no para un número ilimitado de instancias dentro de este host dedicado. Si comparamos con entornos onpremises, incluso un host VMware no puede ejecutar técnicamente un número ilimitado de máquinas virtuales SQL.

Una licencia CAL de SQL Enterprise Server+ cubre el host y, a continuación, ese host está cubierto por un máximo de 4 instancias para un total de 20 vCPU para estas instancias. Si el cliente desea tener más de 4 instancias/20 vCPU ejecutándose en el host, simplemente puede agregar otra licencia CAL de SQL Enterprise Server+ al mismo host para permitir un total de 4 instancias adicionales/20 vCPU. Además, en este modelo de licencia, el cliente también debe tener el número correcto de CAL SQL para cubrir usuarios/dispositivos con acceso directo o indirecto a instancias de SQL Server en el host.

Finalmente, la automatización DH maneja la asignación de host, la asignación de instancias y, lo más importante, la recuperación (por ejemplo la recuperación automática en una zona de disponibilidad (AZ) distinta del DH original). Esto hace que la experiencia de lanzamiento sea consistente con las implementaciones de «shared tenancy».

8. Uso de Block-Level Replication

La replicación en bloques no solo eliminará el requisito de licencia de SQL Core en escenarios de recuperación ante desastres (DR), sino que también eliminará las instancias EC2 que se ejecutarían 24/7 en un entorno de (DR). La replicación de bloques es simplemente copiar los datos desde el disco de origen al disco de destino, en nuestro caso, EBS (Elastic Block store)

Digamos que tenemos una carga de trabajo SQL activa/pasiva usando BYOL y estamos usando los derechos de licencia para uso pasivos, sin embargo, es realmente importante entender que solo tiene derecho a 1 licencia de uso pasivo. ¿Qué sucede si también tenemos como requisito la recuperación ante desastres(DR) para ese mismo entorno? No importa cómo diseñe el nodo DR, ya sea que SQL esté manejando la replicación o incluso el envío de logs, en este caso usted no tendrá los derechos de uso pasivos gratuitos y tendrá que licenciar el entorno  de DR como si se tratara de un entorno activo. Es por eso que usar los grupos de disponibilidad Always On para admitir la recuperación ante un desastre en otra región puede aumentar el costo de la licencia.

¿Cuál podría ser la solución ante esto? Algo tan simple como utilizar la replicación en bloques para el entorno de DR puede proporcionar protección ante desastres sin necesidad de licencias SQL hasta que se ejecute el DR. Esto evita el costo de licencias adicionales requeridas y puede reducir los costos de procesamiento de DR, ya que SQL no se ejecuta hasta que se produce el evento mismo de DR.

Lógicamente, Always On Availability Group es una tecnología superior a la replicación a nivel de bloque. Sin embargo, tenemos que tener en cuenta el costo-beneficio de la solución y especialmente los requerimientos de RPO-RTO (tenga en cuenta que, en la replicación a nivel de bloque, tendremos que configurar el clúster a través de un script o manualmente y esto tomara tiempo).

9) Uso GP2 striping vs. Provisioned IOPS (¡o aun mejor, gp3! J)

El almacenamiento que utiliza el servicio de bloque persistente es un componente crítico y, en última instancia, responsable de la velocidad, la seguridad y la durabilidad de sus datos. AWS proporciona almacenamiento en bloques de alto rendimiento, fácil de usar para satisfacer las necesidades de SQL Server a través del servicio EBS. Aunque usted utilice un único volumen de IOPS aprovisionadas (io1 o io2) para satisfacer sus requisitos de IOPS y rendimiento, los volúmenes SSD de propósito general (gp2) proporcionan el equilibrio de precio y rendimiento que es líder para las cargas de trabajo de SQL Server cuando se configuran correctamente.

Los volúmenes Gp2 proporcionan latencias de milisegundos de un dígito y  capacidad de expansión a 3.000 IOPS durante largos períodos de tiempo. Esta propiedad es adecuada para SQL Server en cargas de trabajo no críticas donde no se requiere un rendimiento máximo las 24 horas del día. Además de esto, la nueva versión de EBS GP3 tiene un menor costo en comparación con GP2 (~ -20%) y no necesita aumentar el tamaño del volumen para aumentar los IOPS!

Si necesita un rendimiento consistente, necesita de soluciones de IOPS aprovisionadas como io1 e io2. IO2 tiene más rendimiento por gigabyte y mucha más durabilidad en comparación con IO1.

Para obtener más información sobre GP2 striping para SQL, haga clic aquí.

10) Ejecución de entornos no productivos con Developer Edition

Aunque puede parecer simple, algunos clientes pagan licencias para su entorno de desarrollo. SQL Server Developer es una edición gratuita con todas funcionalidades completas,  esta licencia puede ser utilizada como base de datos de desarrollo o incluso de prueba en entornos que no sean de producción. Esto significa que se puede desarrollar y probar SQL sin necesidad de obtener licencias pagas. También podemos dar un paso más allá si queremos reducir aun más los costos —por ejemplo,  mirando en el nivel del sistema operativo— con algunas reservas J.

(a) Con SQL en Linux, tenemos el mismo motor de base de datos SQL Server, con características y servicios similares. Algunos clientes eligen ejecutar sus entornos de desarrollo y UAT en Linux. Ubuntu, por ejemplo, será más barato de implementar en comparación con Windows.

(b) Supongamos que tiene un entorno de desarrollo de SQL Server y desea permitir a sus desarrolladores realizar pruebas unitarias, que son, en resumen, probar pequeños cambios en su código. Algunos entornos de desarrollo utilizan incorrectamente licencias de producción. Con MSDN, esto no era un problema real, pero hoy en día puede serlo.

Con AWS Dev fabric para SQL Server, que es una solución de código abierto disponible en github, creada por nuestro equipo de arquitectos para ayudar a nuestros clientes a reducir significativamente el trabajo pesado para configurar entornos de desarrollo en Amazon EC2. Esto es específico para entornos de desarrollo, lo que le permite implementar varias instancias de SQL Server en minutos para soportar las necesidades individuales y minimizar el esfuerzo de los desarrolladores para que en cuestión de minutos tengan los entornos disponibles, y a su vez eliminar las necesidades de licencias de Windows EC2. Esta solución ejecuta Ubuntu Linux en contenedores y trae la posibilidad de ahorrar en comparación de ejecutar sobre instancias Amazon EC2 Windows, lo que lo convierte en una buena opción para entornos de desarrollo en base a una re-plataforma en la capa de la base de datos.

En este blog post, analizamos varias opciones para la reducción de costos de SQL en la nube de AWS. Para obtener más información acerca de SQL en AWS, haga clic aquí.

Sobre el autor

Caio Ribeiro Cesar actualmente trabaja como arquitecto de soluciones especializado en tecnología de Microsoft en la nube de AWS. Comenzó su carrera profesional como administrador de sistemas, que continuó durante más de 14 años en áreas como seguridad de la información, identidad en línea y plataformas de correo electrónico corporativo. Recientemente se hizo fanático de la computación en la nube de AWS y ayuda a los clientes a aprovechar el poder de la tecnología de Microsoft en AWS.

Phil Ekins ha pasado los últimos 25 años trabajando con bases de datos y SQL Server en onpremises, ambientes virtualizados y en la nube. Con una amplia experiencia en la orientación de clientes en arquitecturas de nube, migraciones y soluciones HA / DR, Phil lleva las necesidades de DBA al mundo de la computación en nube.

Javier trabaja actualmente como arquitecto de soluciones y ha trabajado en tecnología de la información durante más de 22 años, comenzando como administrador de sistemas especializado en tecnologías de Microsoft para grandes instituciones financieras siendo especialista en plataformas de correo e intranets corporativa para luego mas tarde en su carrera pasar a tecnologías de virtualización y soluciones de código abierto como Kubernetes.
En la actualidad, se centra principalmente en el diseño y la entrega de nuevas soluciones hibridas sobre la nube AWS, así como en el desarrollo de actividades técnicas con demostraciones y sesiones interactivas para nuestros clientes.