En 2017, ShareGate gastó 250.000 dólares en Azure. Incluso con un MVP de Azure en nuestro equipo ayudándonos a mantener los costes lo más bajos posible, nuestra factura siguió aumentando un 45% en menos de 12 meses. El principal culpable, por supuesto, era la dispersión de la nube.
Sabíamos que era posible un ahorro masivo, así que pedimos a nuestros expertos que nos construyeran una lista de métodos prácticos y efectivos de control de costes en la nube para reducir nuestro gasto en Azure.
Recopilamos nuestros hallazgos en esta guía para que usted también pueda empezar a identificar los posibles ahorros de Azure en los entornos de su organización de inmediato.
Hemos mantenido cada consejo corto, procesable y fácil de entender:
- Considere las máquinas virtuales B-Series virtual machines
- Identifique y actúe sobre los recursos ociosos
- Encuentre el tamaño de recursos adecuado
- Localice y elimine los discos no utilizados
- Aproveche las bases de datos elásticas
- Ensure external users have access to the right things in Teams.
- Consider B-Series virtual machines
- ¿Debo convertir todas mis VMs existentes a B-Series y ahorrar en grande?
- Identificar y actuar sobre los recursos ociosos
- Ensure external users have access to the right things in Teams.
- No tengo un plan de gobierno de costes. Ahora qué?
- Encuentre el tamaño adecuado de los recursos
- Cuándo reducir la escala
- ¿Por qué no puedo ver el uso de la memoria de mi máquina virtual?
- Localice y elimine los discos no utilizados
- Managed disks
- Classic disks
- VHDs olvidados
- Aproveche las bases de datos del pool elástico
- Mejor: Instancias administradas
- Lo mejor: SQL elastic pools
- Time to take action and start saving on Azure
- Ensure external users have access to the right things in Teams.
Ensure external users have access to the right things in Teams.
Consider B-Series virtual machines
While platform-as-a-service (PaaS) offerings have been gaining significant ground over the past few years, virtual machines—be it for legacy reasons or due to specific software requirements—still represent a large portion of cloud usage.
Las máquinas virtuales basadas en la nube presentan un reto en términos de control de costes: suelen requerir especificaciones mínimas para funcionar y a menudo están inactivas con picos de uso periódicos, pero siguen incurriendo en el coste total mientras están encendidas.
En septiembre de 2017, Microsoft anunció la familia de máquinas virtuales B-Series, también conocidas como máquinas virtuales bursátiles. Estas máquinas están diseñadas específicamente para cargas de trabajo que necesitan estar siempre disponibles pero que suelen estar inactivas con picos de uso ocasionales. Las VM de la serie B ofrecen un importante potencial de reducción de costes: entre un 15 y un 55% de descuento sobre el precio de una máquina equivalente de la serie D, dependiendo del sistema operativo que se utilice.
Lectura recomendada: Azure cost-saving tips: dos and don’ts from industry insiders, by Leigh Ryan
¿Debo convertir todas mis VMs existentes a B-Series y ahorrar en grande?
¡Cuidado ahora! No todas las cargas de trabajo pueden convertirse a B-Series a ciegas. Hay que encontrar un equilibrio entre el coste y el consumo de CPU. A los B-Series se les asigna una cantidad básica de CPU. Mientras su uso esté por debajo de la línea de base, la VM acumula créditos, que pueden utilizarse para consumir la CPU que exceda la línea de base. Sin embargo, si su máquina virtual hace un uso demasiado intensivo de la CPU, se reducirá el rendimiento de la línea de base hasta que haya suficientes créditos disponibles.
Las líneas de base y los límites de crédito varían según el tamaño de cada VM de la serie B. Además, cada vez que la VM se apaga, se pierden todos los créditos acumulados. Como tal, las VM B-Series están realmente diseñadas para cargas de trabajo de bajo uso o predecibles que se requieren para estar disponibles en todo momento.
Para ayudarle a determinar si su máquina virtual se puede convertir con seguridad en una B-Series, puede ejecutar scripts personalizados como el script Azure-Burst-Check de Dave Hall.
Identificar y actuar sobre los recursos ociosos
Gracias a Azure, nunca ha sido tan fácil poner en marcha un nuevo entorno en un momento dado cuando se trata de satisfacer una nueva necesidad para su organización. Fast-forward a few years, however, and you’ll start noticing a buildup of resources in your Azure subscription that are likely racking up a hefty bill. It isn’t always easy to tell which workloads are still being used and which ones can safely be decommissioned.
Ensure external users have access to the right things in Teams.
The best solution would be to go back in time and implement a basic cloud asset governance plan. Echa un vistazo a nuestro manual sobre la creación de un plan de gobierno de costes en la nube para obtener una visión general de los elementos principales a tener en cuenta: la visibilidad, la propiedad y los permisos, el ciclo de vida y la optimización, o, como nos gusta llamarlos, VOLO.
En pocas palabras, para cada recurso que cree, querrá:
- Utilizar etiquetas y otras estrategias para categorizar cómo se utilizará el activo (dev, test, prod, etc.)
- Especificar un único propietario para el recurso (normalmente la persona que solicitó el recurso)
- Determinar una fecha de caducidad o de revisión para el recurso (y asegurarse de seguir el calendario y eliminar los recursos innecesarios con prontitud)
- Utilizar un nivel de base de datos más grande y más caro para manejar los picos de uso de las bases de datos
- Utilizar un nivel más bajo para ahorrar costes, a expensas del rendimiento durante los picos
- Alta disponibilidad incorporada (sin necesidad de configurar la replicación)
- Georreplicación activa
- Restauración en tiempo real
Una vez que tenga esta información, es mucho más fácil determinar si un determinado recurso sigue siendo necesario o no y actuar en consecuencia.
Lectura recomendada: Cómo iniciar y detener tus VMs con Azure Automation, por Antoine Jagueneau
No tengo un plan de gobierno de costes. Ahora qué?
Azure te da acceso a un conjunto de estadísticas de uso que miden cuánta actividad están viendo tus recursos. Estos valores se pueden examinar desde el Portal de Azure, accediendo a la API de Azure y utilizando código personalizado, o a través de una solución de gestión de costes dedicada. Al examinar estos números de uso, puede identificar qué activos ya no están en uso (o están significativamente infrautilizados) y tomar las medidas adecuadas. Además, tenga en cuenta que la gobernanza de los costes de la nube es un proceso iterativo, por lo que nunca es demasiado tarde para empezar a trabajar en un plan.
Encuentre el tamaño adecuado de los recursos
Un problema común cuando se crean nuevos recursos en la nube es averiguar el tamaño adecuado a utilizar. Azure ofrece un gran número de opciones para adaptarse a los diferentes requisitos (más memoria RAM, más potencia de CPU, unidades SSD, GPU, etc.), pero incluso dentro de la misma familia de máquinas, elegir el tamaño adecuado importa.
Lectura recomendada: How does Azure VM pricing work?, por Leigh Ryan
Si te equivocas, estarás pagando más de lo que necesitas mientras tu máquina está inactiva, o acabarás con una máquina que está clavada al 100% de uso de la CPU (o incluso peor, intercambiando a la memoria virtual porque se ha quedado sin RAM física). Todo esto, por supuesto, puede impactar significativamente en el rendimiento de la aplicación.
No siempre es fácil averiguar los requisitos de un sistema determinado antes de tiempo, por lo que puede ser tentador ir un poco más alto de lo que necesita sólo para estar en el lado seguro. También es bastante habitual olvidarse de ello y dejarlo sobredimensionado, lo que conlleva costes innecesarios mes tras mes.
¿Cómo se puede evitar esto? ¡Vamos a ver algunas estrategias en este artículo.
La forma más fácil de evitar el desperdicio de dinero en el consumo de recursos innecesarios, sin embargo, es dejar que una herramienta de optimización de la nube dedicada supervise su inquilino y le notifique cada vez que hay una oportunidad para reducir el tamaño, reducir la escala, o de otra manera reducir en un recurso determinado.
Cuándo reducir la escala
Si usted cree que este puede ser el caso de su entorno, no se asuste! Hay algunas formas sencillas de determinar si debe reducir el tamaño de una determinada VM. El método más sencillo es echar un vistazo a los gráficos de Porcentaje de CPU y Porcentaje de Memoria de cada recurso en el Portal de Azure.
Típicamente, los tamaños de las instancias en Azure se duplican con cada nivel: una S1 tendrá 1 núcleo de CPU junto con 1,75 GB de RAM, mientras que una S2 tendrá 2 núcleos y 3,5 GB de RAM. El mismo patrón se aplica también a los tamaños de las bases de datos y las DTUs.
En todos los casos, si ves durante un largo periodo de tiempo que ambas estadísticas de uso están por debajo del 50%, puedes reducir con confianza la escala de tu instancia sin preocuparte por entorpecer el rendimiento.
¿Por qué no puedo ver el uso de la memoria de mi máquina virtual?
Desgraciadamente, no obtendrá los gráficos de porcentaje de memoria para las máquinas virtuales, clásicas o gestionadas, de forma inmediata. Para acceder a esta información, tendrá que habilitar la supervisión a nivel de invitado y comprobar los contadores de rendimiento correctos. El que debe comprobar específicamente es MemoryCommitted Bytes. Con esta información, debería ser capaz de determinar si un servicio puede reducirse de forma segura o no.
Localice y elimine los discos no utilizados
Si ha estado utilizando Azure durante un tiempo, es probable que haya creado -y eliminado- un buen número de máquinas virtuales. Pero su factura sigue subiendo, y no está muy seguro de por qué. Uno de los culpables más probables son los discos de almacenamiento; concretamente, los discos de las máquinas virtuales eliminadas que aún permanecen en su cuenta y que le cuestan dinero mes tras mes. Esto es aún más probable si ha estado utilizando máquinas virtuales clásicas en lugar de la nueva variedad ARM. La razón de esto es bastante simple: Azure no borra sistemáticamente tus discos cuando eliminas una máquina virtual. Esto es para protegerte de la pérdida accidental de datos, pero también significa que si no tienes cuidado, seguirás pagando por discos que ya no necesitas.
Puedes solucionar este problema desde el portal de Azure. The procedure will be a bit different depending on whether you’re dealing with managed disks or classic disks.
Managed disks
For managed disks, go to the Azure portal, search for Disks in the search bar, and select «Disks».
This will display all your managed disks. If the Owner column is empty, it means that the disk is not currently attached to anything and you can probably delete it.
To delete the disk, select the row, go to Overview and click Delete in the top bar.
Classic disks
For classic disks, go to the Azure portal, click in the Search bar up top and search for Disks. Select «Disks (classic)».
You’ll see all of your disks and a column indicating which VM each disk is currently attached to. If you see a disk that isn’t attached to a VM, you can probably delete it safely.
Deleting classic disks is a bit of a process, as the underlying file (the VHD), which is stored in a storage account, will still be there until you manually remove it. Here are the steps:
1. Click on the classic disk and take note of its Storage account and Media link information
2. Click Delete and confirm
3. Usa la barra de búsqueda de Azure para encontrar la cuenta de Almacenamiento que anotaste en el paso 1, luego abre el panel de Propiedades
4. Haz clic en Blobs, luego selecciona la fila con el contenedor de almacenamiento correcto
5. Marque la casilla con el nombre de archivo correcto y, a continuación, haga clic en Eliminar en el menú superior
VHDs olvidados
Aunque siga todos estos pasos para identificar los discos no conectados, es posible que se pierdan VHDs olvidados que se encuentran abandonados en el almacenamiento clásico. Normalmente, el Portal Azure crea un contenedor «vhds» y los coloca allí en una cuenta de almacenamiento. Para localizarlos, busque en cada cuenta de almacenamiento clásico un contenedor vhds en Blobs. Dentro del contenedor, mire la columna de estado de arrendamiento de cada archivo. Si dice Disponible, significa que ninguna VM está utilizando actualmente ese VHD, y puede ser seguro que lo elimine (¡pero siempre debe comprobar el contenido para asegurarse!).
Aproveche las bases de datos del pool elástico
Es probable que haya comenzado su proyecto de migración a la nube moviendo cargas de trabajo que estaban previamente alojadas on-prem o en un centro de datos privado a Azure. Un gran número de estas cargas de trabajo probablemente utilizaban bases de datos de SQL Server, que solían ser la columna vertebral de la mayoría de los proyectos de software antes del auge de la nube y del movimiento NoSQL. También es probable que hayas notado que los precios de las bases de datos SQL en Azure pueden llegar a ser bastante elevados, con bastante rapidez.
Mientras que antes podías utilizar un único servidor de bases de datos para alojar docenas, si no cientos, de bases de datos para tus diversos proyectos o clientes, el coste de dividirlas en bases de datos SQL de Azure separadas podría ser órdenes de magnitud más altas de lo que esperabas. Esto se debe a cómo funcionan las bases de datos en Azure. En la versión local, estaba acostumbrado a que varias bases de datos compartieran los recursos limitados de un único servidor. Con Azure SQL, cada base de datos tiene una cantidad reservada de recursos, por los que se le cobrará incluso si la base de datos está inactiva. El modelo es excelente si tiene varias bases de datos con una utilización constante y predecible. Sin embargo, si tiene un gran número de bases de datos con un patrón de uso espigado, puede encontrar la etiqueta de precio significativamente menos atractiva. Esto le deja con dos opciones:
Para compartir los recursos entre las bases de datos, los primeros adoptantes de Azure se vieron obligados a crear y mantener sus propias máquinas virtuales con SQL Server instalado y, esencialmente, a replicar las condiciones en las que se ejecutaban mientras estaban on-prem o en un centro de datos privado. Aunque este método funcionaba bien, no permitía acceder a todas las grandes características que Azure SQL ofrece, como:
Estas características no son triviales para desplegar por su cuenta y pueden ser un reto para mantener.
Mejor: Instancias administradas
Azure ofrece un nivel más nuevo de servicios de bases de datos SQL llamados instancias administradas, que son esencialmente máquinas virtuales administradas que alojan un SQL Server. Las instancias gestionadas no le proporcionarán todas las características que se incorporan en los servicios de base de datos única de Azure SQL, pero tampoco tendrá que gestionar el sistema operativo o la instalación de SQL Server. Básicamente, estás obteniendo una máquina virtual cuya configuración y mantenimiento se maneja en gran medida por ti.
Lo mejor: SQL elastic pools
Pero hay otra opción en Azure para abordar este escenario común: SQL elastic pools. En lugar de reservar una determinada cantidad de recursos para una sola base de datos, los pools elásticos de SQL te permiten reservar una serie de recursos y compartirlos entre cientos de bases de datos. Este modelo tiene todos los beneficios de Azure SQL y le permite manejar adecuadamente los patrones de uso puntuales en múltiples bases de datos. Los pools elásticos han demostrado ser increíblemente populares y son una opción ideal para las aplicaciones multi-tenanted.
Sin embargo, debe ser cauteloso en el uso de los pools elásticos. Si tiene una o más bases de datos con un uso significativamente mayor que las otras bases de datos en un pool, puede verse obligado a comprar un nivel de pool elástico más caro para manejar los picos de uso. En algunos casos, puede ser más rentable dividir estas bases de datos de alto uso en ofertas de bases de datos individuales (sacándolas del pool) y pagar por un nivel más pequeño de pool elástico para el resto de bases de datos de menor uso. Una buena regla general es fijarse en el uso de DTU de la base de datos: si una sola base de datos está utilizando el 40% o más de los DTU del pool elástico en un momento dado, es posible que pueda ahorrar costes separándola del pool, y luego escalando dicho pool a un nivel menos caro.
Como siempre, el portal de Azure es su recurso para identificar los patrones de uso de la base de datos.
Time to take action and start saving on Azure
By acting on the five areas outlined in this guide, our team managed to shrink our Azure spend by 30%.
Can you do better?
Ensure external users have access to the right things in Teams.
Get full visibility into who’s shared what with whom, and automate external sharing reviews so they’re performed on an ongoing basis.