Cuando creo una VM de SQL Server en Azure, la plantilla ARM que nos despliega por defecto nos monta un servicio muy completo con una máquina virtual, red virtual, vNic, nsg, ip pública y discos duros; finalizando con la instalación de una Instancia de SQL.
Una de las cosas que primero escojo con cuidado es la familia y el tamaño de la VM, para ajustar al máximo el coste inicial con las necesidades de computación que preveo, y que evolucionaré en el tiempo.
Hace poco, para un curso de la certificación DP-300, he montado una SQL sobre D8s_v5 en donde hacer los laboratorios de prácticas, y me he fijado en el coste mensual previsto que me muestra el portal de Azure de una máquina relativamente «grande» para los poquitos recursos que se necesitan: 235€ mensuales en East Us.
Lo cual no es cierto, ni cercanamente.
Este es el coste solo de la capacidad de computación. Pero hay que añadirle otros 247€ por la licencia de Windows Server 2022; y, según la licencia de la instancia de SQL que elija, debo añadirle, Developer (0€), Web (522€), Standard (1.018€) o Enterprise (2.498€), a la factura mensual.
Aun así, partiendo de que tengo la máquina encendida unas pocas horas al día, y que la destruyo en cuanto termino el curso de cuatro días, el coste es asumible ya que no llega ni a los 3€ en total. Sin embargo, al revisar el Cost Managment, me encuentro con un coste de casi 5€ al día, que me sorprende.
Revisando el informe diario de gasto, veo que quien lo está produciendo son los tres discos duros que la imagen de la VM de SQL Server ha implementado por defecto, y los ha configurado de 1 Tb de almacenamiento, y Premium SSD. Es decir, tres P30, a 125€ al mes, poco más de 4€ al día, por cada uno. Casi 13€ cada día, estén llenos o vacíos…¡!
Solución buena: analizar que capacidades de almacenamiento, de IOPS y de ancho de banda necesito en mis discos duros. Apagar la máquina virtual. Cambiarle el tipo de Disco Gestionado a un SSD Standard o, aún mejor si se puede, a un HDD Standard.
No quiero caer en la tentación de presuponer falta de rendimiento: lo tengo que medir. Monto un panel de métricas, o hago un seguimiento en el Query Store, o uso la vista de sistema adecuada para, partiendo de una línea base, saber si hay demasiada presión en las operaciones E/S de los discos duros.
Solución óptima: Borrarlo todo, y modificar la plantilla de implementación para hacer los discos duros lo más pequeños posible (creo que son 32Gb, por defecto) y lo más lentos posibles. Partiendo de una buena línea base, los voy a ir haciendo más rápidos y/o más grandes.
Pero que los requisitos sean los que tiren de los recursos, y no al revés.
Espero que sea de utilidad.