Introducción
En el ecosistema de Microsoft Azure, el almacenamiento es mucho más que un simple espacio para guardar archivos; es el motor que determina la latencia y la capacidad de respuesta de tus aplicaciones. Tradicionalmente, muchos administradores ven los discos como un componente “pegado” a una máquina virtual, pero para un Cloud Engineer, los Azure Managed Disks son recursos independientes con su propio ciclo de vida y métricas de rendimiento críticas.
En este artículo, aprenderás a gestionar el almacenamiento en bloque de forma profesional. Exploraremos desde la física detrás del rendimiento (IOPS y ancho de banda) hasta operaciones críticas de infraestructura como código, como la expansión de discos sin tiempo de inactividad y la creación de estrategias de respaldo mediante snapshots. Al finalizar, tendrás el control total sobre tus recursos de almacenamiento, optimizando tanto los costos como la eficiencia operativa.
Requisitos Previos
Para seguir este tutorial y ejecutar los comandos de Azure Managed Disks CLI, necesitarás contar con el siguiente entorno:
- Visual Studio Code: El editor preferido para gestionar scripts.
- Azure CLI: Instalado en tu sistema operativo (Windows, macOS o Linux/Ubuntu).
- Extensión de Azure Account para VS Code: Para una autenticación fluida.
- Cuenta de Azure Activa: Con permisos de “Colaborador” en la suscripción.
- Terminal configurada: Ya sea Bash o PowerShell integrado en VS Code (este tutorial utiliza sintaxis compatible con Bash).
Repositorio en GitHub
https://github.com/DavidGonzalezCloud/azure-cli-journey.git
Fundamentos de Arquitectura
Managed vs. Unmanaged Disks
En la nube moderna, Microsoft gestiona el hardware físico, la replicación y la ubicación por ti a través de los Managed Disks. Tú solo defines la capacidad y la velocidad; Azure se encarga del resto, eliminando la complejidad de las antiguas Cuentas de Almacenamiento (Storage Accounts).
La Física del Rendimiento: IOPS y Throughput
El rendimiento de un disco no es magia, es física de datos. Debes entender la relación entre tres variables: IOPS (operaciones de entrada/salida por segundo), Throughput (ancho de banda en MB/s) y el Tamaño de Bloque.
La fórmula que rige este comportamiento es:
SKUs y Redundancia
No todos los discos son iguales. La elección depende de tu carga de trabajo y presupuesto:
- Standard SSD (LRS): Ideal para servidores web ligeros o entornos de desarrollo.
- Premium SSD (LRS/ZRS): Necesario para bases de datos productivas. ZRS (Zone-Redundant Storage) ofrece alta disponibilidad al replicar los datos en tres zonas de disponibilidad distintas dentro de una región.
Paso a Paso: Gestión con Azure CLI
Paso 1: Aprovisionamiento Aislado (Modularidad)
En el aprovisionamiento tradicional (o cuando usamos el Portal web para ir rápido), la mayoría de los administradores crean la Máquina Virtual y dejan que Azure genere el disco del sistema operativo y los de datos por defecto. El problema de ese enfoque es el acoplamiento: si la VM se elimina por error, los discos suelen irse con ella, lo que puede causar pérdida de datos catastrófica.
Al crear el almacenamiento de forma independiente mediante Azure CLI, adoptamos la mentalidad de “Cero Configuraciones por Defecto”. Desacoplamos el ciclo de vida del disco del de la VM. Esto significa que tú decides explícitamente el tipo de hardware (SKU), el tamaño exacto y la ubicación antes de que cualquier servidor interactúe con él. Esta es una mejor práctica fundamental para la resiliencia de los datos, asegurando que el almacenamiento persista de forma independiente a la infraestructura de cómputo.
# Definición de variables globales
RG_NAME="rg-estudio-discos"
LOCATION="eastus"
DISK_NAME="DataDisk-Lab-01"
DISK_NAME_PROD="DataDisk-Prod-ZRS"
# Creación del contenedor lógico (Grupo de Recursos)
az group create \
--name $RG_NAME \
--location $LOCATION
# Creación del Disco Estándar (Para pruebas económicas)
az disk create \
--resource-group $RG_NAME \
--name $DISK_NAME \
--sku StandardSSD_LRS \
--size-gb 4 \
--location $LOCATION
# Creación del Disco Premium (Para alta disponibilidad zonal)
az disk create \
--resource-group $RG_NAME \
--name $DISK_NAME_PROD \
--sku Premium_ZRS \
--size-gb 4 \
--location $LOCATION
Paso 2: Auditoría de Rendimiento con JMESPath
Cuando ejecutas un comando de lectura en Azure CLI, el motor de Azure Resource Manager (ARM) te devuelve un enorme y complejo documento JSON lleno de metadatos del recurso. Buscar información vital ahí a simple vista es ineficiente y propenso a errores.
Aquí es donde brilla JMESPath, el poderoso lenguaje de consulta integrado en el parámetro --query. En lugar de navegar ciegamente por el Portal de Azure, usamos JMESPath como un bisturí para extraer exclusivamente las métricas de rendimiento físico real que Azure nos ha asignado por detrás: diskIOPSReadWrite y diskMBpsReadWrite. Realizar esta auditoría es un paso obligatorio en entornos de producción para certificar que el disco aprovisionado cumple estrictamente con el SLA de rendimiento (Throughput) que exige tu base de datos antes de salir a producción.
# Auditoría del Disco Premium Zonal (Premium - ZRS)
az disk show \
--resource-group $RG_NAME \
--name $DISK_NAME_PROD \
--query "{Nombre:name, Nivel:sku.name, IOPS:diskIOPSReadWrite, MBps:diskMBpsReadWrite}" \
--output table
Paso 3: Expansión en Caliente (Hot Resize)
Una de las grandes promesas de la nube es la elasticidad, pero el almacenamiento en bloque tiene una “Ley de Hierro” inquebrantable en Azure: los discos administrados pueden expandirse, pero nunca encogerse. Esto se debe a que Azure, a nivel físico, no tiene visibilidad de cómo el sistema operativo (tu Windows o Linux) ha distribuido los bloques de archivos a nivel de la partición lógica; intentar reducir el disco corrompería los datos irremediablemente.
La “expansión en caliente” te permite aumentar la capacidad y el rendimiento instantáneamente, sin necesidad de apagar la máquina virtual a la que está conectado.
💡 Nota del Cloud Engineer: Recuerda que con este comando Azure expandirá la “caja física” (el Managed Disk). Sin embargo, para que tu aplicación pueda usar ese espacio, posteriormente deberás entrar al sistema operativo de la máquina virtual (usando Disk Management en Windows o comandos como resize2fs en Linux) para expandir la partición lógica.
# Expansión del disco a 16 GB
az disk update \
--resource-group $RG_NAME \
--name $DISK_NAME \
--size-gb 16
# Confirmación del cambio
az disk show --resource-group $RG_NAME --name $DISK_NAME --query "diskSizeGB"
Paso 4: Snapshots y Clonación
Los Snapshots (Instantáneas) son copias exactas, de solo lectura, del estado de un disco en un momento específico en el tiempo (point-in-time). Son la columna vertebral de cualquier estrategia seria de Disaster Recovery.
Un truco vital de optimización de costos en la industria es almacenar siempre tus snapshots utilizando almacenamiento mecánico (Standard_LRS). Dado que un snapshot es información “fría” que solo se usa como respaldo de emergencia, no tiene ningún sentido financiero pagar las costosas tarifas del almacenamiento Premium por él. En el código a continuación, no solo tomamos la instantánea ahorrando dinero, sino que extraemos su identificador único (ID) para usarlo como “molde” y generar un disco físico completamente nuevo. Esta técnica de clonación es ideal para entornos de QA: puedes clonar el disco de producción, conectarlo a un servidor de pruebas y validar actualizaciones sin poner en riesgo los datos reales.
SNAPSHOT_NAME="Snap-DataDisk-Lab-01-v1"
NEW_DISK_NAME="DataDisk-Clone-01"
# Toma del Snapshot (Usamos SKU barato para ahorrar)
az snapshot create \
--resource-group $RG_NAME \
--name $SNAPSHOT_NAME \
--source $DISK_NAME \
--sku Standard_LRS
# Extraer ID del Snapshot
SNAPSHOT_ID=$(az snapshot show -g $RG_NAME -n $SNAPSHOT_NAME --query id -o tsv)
# Clonar el disco a partir del Snapshot
az disk create \
--resource-group $RG_NAME \
--name $NEW_DISK_NAME \
--source $SNAPSHOT_ID \
--sku StandardSSD_LRS
Paso 5: Prevención del “Cloud Waste”
Uno de los mayores sumideros de presupuesto en cualquier factura de nube (lo que llamamos “Cloud Waste”) son los famosos “discos huérfanos”. A diferencia de las máquinas virtuales —que dejan de cobrar por el poder de cómputo en cuanto las apagas—, los discos administrados se facturan 24/7 por su capacidad total aprovisionada, sin importar si están vacíos o si ni siquiera están conectados a un servidor.
Por lo tanto, la limpieza de la infraestructura debe ser implacable. En tuberías de despliegue (CI/CD), solemos usar un borrado granular (eliminando recursos uno por uno). Sin embargo, para laboratorios técnicos o pruebas efímeras como esta, el borrado “nuclear” asíncrono (--no-wait) es la herramienta más eficiente: le ordena a Azure que destruya todo el contenedor lógico y su contenido en segundo plano, devolviéndote el control de la terminal inmediatamente.
# Borrado Nuclear: Elimina todo el laboratorio de una vez
az group delete --name $RG_NAME --yes --no-wait
Conclusión
Gestionar Azure Managed Disks CLI de forma independiente te otorga una flexibilidad y control sobre el rendimiento que no obtienes simplemente haciendo clic en el portal. Hemos cubierto desde la teoría física del almacenamiento hasta la implementación práctica de expansiones y snapshots, resolviendo además errores comunes de sintaxis en la terminal.
¿Te ha surgido algún problema al intentar expandir tus discos o al consultar las métricas? ¡Déjame tus dudas en los comentarios y sigamos construyendo en la nube!
