Ajuste de tamaño de máquinas virtuales de Azure: una guía práctica

El ajuste de tamaño de máquinas virtuales de Azure es la práctica de hacer coincidir el tamaño de una máquina virtual, su SKU, con la CPU, la memoria y la red que realmente utiliza, en lugar del tamaño con el que se desplegó por casualidad. En la mayoría de los entornos algunas máquinas se dimensionaron para un pico de lanzamiento o se trasladaron desde equipos locales, y han funcionado bajo ese techo desde entonces. Para ajustar bien el tamaño de las máquinas virtuales de Azure, reúna evidencia de utilización durante un periodo representativo, normalmente 30 días, encuentre las máquinas cuyo uso sostenido y máximo quede muy por debajo de su capacidad aprovisionada, y luego muévalas a una SKU más pequeña con un margen sensato. Hecho con evidencia en lugar de con una corazonada, es una de las formas más repetibles de reducir el coste de cómputo de Azure mientras la carga de trabajo sigue funcionando.

Esta guía recorre el bucle completo: por qué las máquinas acaban sobredimensionadas, cómo recoger la evidencia, leer las recomendaciones de Advisor, elegir un tamaño objetivo, redimensionar una máquina virtual de Azure con seguridad y registrar el resultado. Las cifras son orientativas, porque dependen de su entorno, pero el método se aplica en cualquier parte.

Por qué las máquinas virtuales acaban sobredimensionadas

El sobredimensionamiento rara vez empieza como un error. Empieza como cautela que nunca se vuelve a revisar.

• Dimensionada para el pico de lanzamiento. Una máquina se aprovisiona para el día más ajetreado que pueda llegar a ver, una migración de corte, un lanzamiento, un pico estacional, y luego pasa el día de mucho trajín y el tamaño se queda.
• Hábitos de traslado tal cual. Cuando una carga de trabajo pasa de un servidor físico o local, los equipos a menudo igualan uno a uno los antiguos recuentos de núcleos y memoria, aunque aquella máquina se comprara con años de margen ya incorporados.
• El margen como seguro. Un tamaño mayor se siente más seguro que una decisión que resulte algo justa, así que la opción de aspecto más seguro gana por defecto.
• Nadie es dueño de la revisión. El tamaño se fija una vez en el despliegue y nunca se contrasta con lo que hace la máquina, así que la factura refleja en silencio una decisión que ya no se sostiene.

Ninguna de estas es irrazonable en el momento. El problema es que el momento termina y el tamaño no.

Reúna la evidencia con Azure Monitor

Ajustar el tamaño sin datos es adivinar con pasos de más, así que empiece por la utilización. Azure Monitor recopila métricas de plataforma para cada máquina virtual de forma automática, sin ningún agente ni configuración.

En el portal, abra Máquinas virtuales, seleccione la máquina y luego, en Supervisión, elija Métricas para gráficos en bruto o Información y luego la pestaña Rendimiento para una vista curada. La métrica que más importa para dimensionar el cómputo es Percentage CPU, una métrica de plataforma a nivel de host reportada como porcentaje con una granularidad de un minuto y una agregación de promedio por defecto. No juzgue solo por el promedio: represente la línea sostenida y el percentil 95 juntos, porque una máquina puede parecer tranquila de media y aun así necesitar margen para ráfagas cortas y regulares. El gráfico de uso de CPU de la vista de Rendimiento usa por defecto el promedio y el percentil 95 superior.

La memoria requiere algo de cuidado. Las métricas de plataforma del host exponen Available Memory Bytes, pero los contadores granulares a nivel de invitado que rastrean cuánta memoria está comprometiendo realmente el sistema operativo se recopilan a través del Azure Monitor agent dentro de la máquina, no por defecto. Si planea dimensionar también por memoria además de por CPU, ponga el agente en su sitio primero y luego lea la memoria disponible durante la misma ventana. El gráfico de memoria disponible de la vista de Rendimiento usa por defecto el promedio más el percentil 5 y 10 superiores, mostrando los momentos ajustados en lugar de los cómodos.

Mire al menos 30 días para que un fin de semana tranquilo o una semana ajetreada no distorsionen el panorama. Lo que quiere antes de actuar es una máquina cuya CPU en el percentil 95 y cuya memoria disponible más baja queden ambas cómodamente por debajo de su tamaño aprovisionado.

El bucle de ajuste de tamaño funciona con evidencia: medir, preseleccionar, comprobar límites, redimensionar, luego verificar y registrar.

Lea las recomendaciones de Azure Advisor

Una vez que tenga una idea de la utilización, deje que Azure Advisor haga el trabajo pesado de reconocer patrones. En Advisor y luego la pestaña Costes, busque Right-size or shutdown underutilised virtual machines. Advisor usa modelos de aprendizaje automático sobre su uso para sugerir un redimensionamiento o un apagado para cada candidato, y muestra el tamaño actual y el objetivo para un redimensionamiento.

Ayuda saber a alto nivel cómo se derivan, para poder confiar en ellas sin tratarlas como dogma:

• Las recomendaciones de apagado señalan máquinas efectivamente sin uso durante la ventana de retrospección. Los criterios usan la utilización de CPU y de red saliente, no la memoria, y se sugiere un apagado cuando, por ejemplo, el percentil 95 de la CPU máxima sumada entre núcleos se mantiene por debajo del 3 por ciento y la red saliente por debajo del 2 por ciento.
• Las recomendaciones de redimensionamiento pueden cruzar familia y versión de SKU, y tienen en cuenta restricciones como si el objetivo admite redes aceleradas y almacenamiento premium, si está disponible en la región y si la máquina está en un conjunto de disponibilidad.
• El periodo de retrospección es de siete días por defecto pero se puede configurar a 7, 14, 21, 30, 60 o 90 días, y un cambio puede tardar hasta 48 horas en propagarse. También puede filtrar qué máquinas aparecen estableciendo un umbral de CPU promedio en Configuración y luego la pestaña VM/VMSS right sizing (derechos de propietario de la suscripción, hasta 24 horas para aplicarse), lo que cambia lo que ve, no cómo se generan las recomendaciones.

Dos salvedades honestas. Las cifras de ahorro de Advisor usan tarifas de venta al público e ignoran cualquier descuento de reserva o de plan de ahorro que tenga, así que el titular puede leerse más alto de lo que realizará. Y el ahorro anual potencial completo que se muestra es para apagar una máquina o eliminarla; redimensionar suele ahorrar dinero real, pero no esa cantidad completa. Trate las recomendaciones como una preselección fuertemente evidenciada, no como una promesa.

Elija la SKU objetivo

La sugerencia de Advisor es un punto de partida, no la única opción. Cuando elija un tamaño objetivo, sopese varias cosas a la vez.

• Encaje de familia. La serie D de uso general encaja con cargas equilibradas, la serie E optimizada para memoria encaja con bases de datos y cachés, la serie F optimizada para cómputo encaja con trabajo ligado a la CPU, y la serie B ampliable encaja con cargas de promedio bajo con picos. Bajar dentro de la familia correcta es más limpio que saltar entre familias.
• Tamaños de núcleos restringidos. Donde la licencia por núcleo es el verdadero impulsor del coste, los tamaños de vCPU restringidos conservan la memoria, el almacenamiento y el ancho de banda de una SKU mayor mientras reducen el recuento de núcleos facturable.
• Disponibilidad regional. Un tamaño ofrecido en una región puede no existir en otra, así que confirme que el objetivo está disponible donde vive la máquina.
• Límites de disco y de red. El máximo de discos de datos, IOPS, rendimiento y recuentos de interfaces de red están todos ligados al tamaño. Bajar demasiado puede limitar una máquina que nunca estuvo ligada a la CPU, así que compruebe los límites del objetivo frente a lo que la carga de trabajo conecta y mueve.

Deje margen. El objetivo es un tamaño que cubra cómodamente la carga del percentil 95, no uno que se caliente la primera tarde de mucho trajín.

Realice el redimensionamiento, y espere un reinicio

Redimensionar es rápido, pero disruptivo, así que planifíquelo como tal. Cambiar el tamaño de una máquina virtual en funcionamiento provoca su reinicio, mejor hecho en horas de menor actividad. Si el tamaño objetivo no está disponible en el clúster de hardware que aloja actualmente la máquina, primero debe desasignarla, lo que detiene la máquina, libera cualquier dirección IP pública dinámica y puede borrar el disco temporal; los discos del sistema operativo y de datos no se ven afectados.

Hay tres formas comunes de hacerlo:

• Portal. Abra la máquina, vaya a Disponibilidad + escalado y luego Tamaño, elija de la lista disponible y seleccione Cambiar tamaño.
• Azure CLI. Enumere las opciones del clúster con az vm list-vm-resize-options, luego ejecute az vm resize --size <NewSize>. Si el tamaño no aparece, az vm deallocate primero, redimensione, luego az vm start.
• PowerShell. Enumere las opciones con Get-AzVMSize, establezca $vm.HardwareProfile.VmSize y luego aplique con Update-AzVM.

Si la máquina está en un conjunto de disponibilidad y el nuevo tamaño no está en el clúster actual, puede que necesite desasignar antes cada máquina del conjunto. Prográmelo y avise al propietario de la carga de trabajo antes, no después.

Verifique el cambio y registre el ahorro

Un redimensionamiento no termina cuando la máquina reinicia. Vuelva a comprobar las mismas métricas de uso de CPU y de memoria disponible de Azure Monitor durante los días siguientes para confirmar que el tamaño más pequeño se sostiene bajo carga real con el margen intacto. Si se calienta, suba un escalón; eso es parte del bucle, no un fracaso.

Luego registre la evidencia. Anote el tamaño de antes y después y el movimiento de coste mensual, y conserve la exportación de costes de Advisor (pestaña Costes de Advisor, descarga como CSV) como línea de base. Ese registro de antes y después convierte un cambio técnico en un ahorro defendible cuando finanzas o un propietario pregunten qué cambió.

Conviértalo en una cadencia, no en algo puntual

La deriva de tamaño es continua, así que una sola pasada no basta. Los patrones de uso cambian y las cargas de trabajo se mueven, así que la decisión correcta de ayer se convierte en el sobredimensionamiento del próximo trimestre. Ponga el ajuste de tamaño en una revisión mensual o trimestral para que el entorno siga rastreando la utilización observada en lugar de una suposición del día del despliegue. Se sitúa junto a la eliminación de desperdicio en un sentido más amplio; para los recursos que facturan mientras hacen poco o ningún trabajo, vea cómo los recursos de Azure inactivos se convierten en deuda de diseño en la factura.

Dónde encaja EtherInsights

Ejecutar este bucle a mano en un puñado de máquinas es manejable. En un entorno en crecimiento, o en muchos clientes para un proveedor de servicios gestionados, rápidamente se convierte en un trabajo en sí mismo, y ahí es donde EtherInsights se gana su lugar. Saca a la luz las máquinas virtuales sobredimensionadas e infrautilizadas a partir de evidencia de utilización, enmarca cada una como una acción respaldada por un propietario en lugar de como una métrica en bruto, y realiza el seguimiento del antes y el después para que un redimensionamiento repose en pruebas en lugar de en una corazonada.

Ese enfoque de la evidencia primero es todo el sentido de nuestro servicio de ajuste de tamaño de máquinas virtuales de Azure, que convierte los datos de utilización en acciones de redimensionamiento que su equipo puede evaluar y asumir, con las cifras para respaldarlas. El cómputo es solo una línea de la factura, así que reunir el ajuste de tamaño con el trabajo de licencias, almacenamiento y recursos inactivos bajo un único programa de optimización de costes en la nube mantiene al entorno pagando por el trabajo que realmente hace, no por la forma que se le dio al principio.

El ajuste de tamaño no es una limpieza puntual ni un recorte tosco de costes. Es un bucle disciplinado y guiado por la evidencia: medir, preseleccionar, comprobar los límites, redimensionar con cuidado, luego verificar y registrar. Trabájelo en una cadencia y el cómputo de Azure seguirá coincidiendo con la demanda real en lugar de con una suposición que expiró hace mucho.

Explore el ajuste de tamaño de máquinas virtuales de Azure para ver cómo la evidencia de utilización se convierte en acciones de redimensionamiento respaldadas por un propietario con las pruebas para sostenerlas.