Hola a tod@s,
En el post anterior vimos cómo escalar Azure Local utilizando arquitecturas como Multi‑Rack, pero hoy vamos a dar un paso más allá.
Porque hay una pregunta que tarde o temprano aparece en cualquier entorno:
¿Qué pasa cuando necesito escalar almacenamiento… pero no con cómputo?
Y aquí es donde entra un modelo que cambia completamente el enfoque:
Las implementaciones desagregadas en Azure Local
El límite del modelo hiperconvergente
Durante años, Azure Local (antes Azure Stack HCI) se ha basado en un modelo claro:
- Cada nodo aporta cómputo
- Cada nodo aporta almacenamiento
- Todo está integrado
Esto funciona muy bien en escenarios pequeños y medianos, pero en entornos reales (datacenter Enterprise):
- El consumo de storage crece más rápido que el computo
- O al revés
- Se pierde eficiencia en costes
Y empiezas a añadir nodos… solo para tener más discos
Ahí es cuando HCI deja de ser la mejor opción.
¿Qué es una implementación desagregada?
El concepto es simple, pero el impacto es enorme:
Separar computo y almacenamiento
En lugar de:
Nodo = CPU + RAM + discos
Pasamos a:
- Nodos → solo cómputo
- SAN → almacenamiento externo
- Red → interconecta todo
Vista lógica de arquitectura
Aquí podemos ver cómo cambia completamente la arquitectura:
Qué estamos viendo:
- Clúster de Azure Local (Hyper‑V + Failover Cluster)
- SAN externa (FC / iSCSI)
- Integración con Azure (Arc, Monitor, Defender)
Este es el salto real: dejamos de depender del almacenamiento local.
Arquitectura de red: imprescindible en este modelo
Cuando separamos capas, la red se vuelve crítica.
Y aquí entra el diseño que ya es estándar en datacenter:
Leaf-Spine
En este modelo:
- Cada rack tiene sus switches (leaf) accesos (donde conectamos los servidores).
- Los spines son los switches principales que interconectan todo.
Esto nos permite:
- Escalar horizontalmente
- Reducir latencia
- Mejorar resiliencia
Es el mismo patrón que utilizan los hyperscalers.
Redes y seguridad (lo realmente importante en producción)
Aquí es donde vemos la diferencia entre un laboratorio… y un entorno real.
Segmentación de red
En desagregado, no todo va por la misma red:
- Mgmt / Compute → Ethernet
- Cluster → tráfico interno
- Storage → red dedicada (FC / iSCSI)
El tráfico de almacenamiento va aislado
Esto mejora:
- Rendimiento
- Estabilidad
- Seguridad
Seguridad y gobernanza con Azure
Una de las grandes ventajas de Azure Local es esto:
El control sigue estando en Azure
Gracias a:
- Azure Arc
- Azure Policy
- Microsoft Defender for Cloud
Podemos:
- Aplicar compliance
- Detectar vulnerabilidades
- Tener visibilidad centralizada
Es decir, tenemos modelo cloud… en nuestro datacenter.
Ventajas reales de este modelo
Después de ver todo, esto es lo importante:
Escalabilidad independiente
- Añadimos computo sin tocar storage
- Amplíanos SAN sin tocar nodos
Mejor aprovechamiento de infraestructura
- No compramos CPUs innecesaria
- Usamos nuestra SAN existente
Rendimiento superior
- Storage optimizado
- Menos contención en nodos
Arquitectura Enterprise real
- Modelo utilizado en grandes Datacenters
- Preparado para crecer
Desde mi punto de vista, esto es un cambio enorme para Azure Local.
Hasta ahora:
Azure Local era excelente… pero limitado por HCI
Ahora:
Azure Local puede competir directamente con arquitecturas tradicionales de datacenter
Y eso significa una cosa:
Azure Local Deja de ser solo “edge” o “ROBO = Remote Office / Branch Office”
y entra en el mundo Enterprise de verdad.
En resumen, Azure Local deja de ser una solución orientada únicamente a escenarios Edge (procesamiento local cercano al origen de los datos) o entornos ROBO, y pasa a posicionarse como una plataforma válida para arquitecturas de datacenter Enterprise.
Las implementaciones desagregadas no sustituyen HCI.
Pero sí lo complementan.
HCI para simplicidad
Desagregado para escala real
como arquitectos, lo importante no es elegir uno…
sino saber cuándo usar cada modelo.
Ya sabemos otra forma de despliegue de Azure Local.
Nos vemos en el próximo artículo.
Saludos.