Entender la arquitectura de Azure es una tarea esencial para el examen AZ-900. Azure se divide en infraestructura fisica (donde estan los servidores) y estructura logica (como se agrupan y gestionan los recursos). Las analogias de la red logistica nacional y el sistema de archivo de empresa lo hacen todo claro de una vez.
La estructura completa de un vistazo
Toda la infraestructura de Azure se divide en dos dimensiones.
La dimension fisica aborda "donde en el mundo estan los servidores de Azure". Centros de datos, regiones, zonas de disponibilidad y pares de regiones pertenecen aqui.
La dimension logica aborda "como se agrupan y gestionan los recursos de Azure". Recursos, grupos de recursos, suscripciones y grupos de gestion pertenecen aqui.
Infraestructura fisica — La analogia de la red logistica nacional
Imagina una gran empresa de mensajeria que opera centros logisticos en multiples ciudades del pais. Centros independientes operan en Madrid, Barcelona, Valencia y Sevilla. Si el centro de una ciudad tiene un problema, los otros siguen funcionando normalmente. Las regiones de Azure son exactamente esos centros logisticos.
Centros de datos (Data Centers)
Todo en Azure comienza con los centros de datos fisicos. Un centro de datos es un edificio lleno de servidores reales, equipos de red y almacenamiento. Azure opera cientos de centros de datos en todo el mundo. Cada centro tiene suministros de energia independientes, sistemas de refrigeracion y conexiones de red. Por seguridad, el publico no puede visitarlos y las ubicaciones exactas no se divulgan.
Regiones (Regions)
Una region es una coleccion de multiples centros de datos ubicados en la misma area geografica. Azure opera mas de 60 regiones en todo el mundo, mas que cualquier otro proveedor de nube.
Lista de regiones de muestra
| Area | Nombre de region | |------|----------------| | Corea del Sur | Korea Central (Seoul), Korea South (Busan) | | Estados Unidos | East US (Virginia), West US (California), Central US (Iowa) | | Europa | North Europe (Irlanda), West Europe (Paises Bajos) | | Asia | East Asia (Hong Kong), Southeast Asia (Singapur) | | Japon | Japan East (Tokio), Japan West (Osaka) |
Que considerar al elegir una region
Latencia: Elegir la region mas cercana a los usuarios finales acelera los tiempos de respuesta. Para un servicio dirigido a usuarios coreanos, Korea Central es la mejor opcion. Soberania de datos: Algunas leyes nacionales exigen que ciertos tipos de datos se almacenen solo dentro del pais. Por ejemplo, el GDPR de la UE puede requerir que los datos de ciudadanos europeos permanezcan en Europa. Disponibilidad de servicios: No todos los servicios de Azure estan disponibles en todas las regiones. Al usar un servicio especifico, debes elegir una region que lo soporte. Costo: Los precios pueden diferir por region. East US suele ser de los mas economicos. Cumplimiento: Ciertos sectores (finanzas, salud) pueden tener regulaciones que requieren el uso de centros de datos en ubicaciones especificas.
Zonas de disponibilidad (Availability Zones)
Ahora piensa en un centro logistico (region) que opera multiples edificios independientes. El Edificio A, B y C tienen cableado, refrigeracion y conexiones a internet independientes. Si el Edificio A se incendia, los Edificios B y C siguen operando. Eso es una Zona de disponibilidad.
Una Zona de disponibilidad es un centro de datos fisicamente separado dentro de una sola region. Cada zona tiene su propio suministro de energia independiente, sistema de refrigeracion y redes, de modo que si una zona cae completamente, no afecta a las otras. Una region tipicamente tiene tres zonas de disponibilidad.
Como usar las Zonas de disponibilidad
Servicios con redundancia de zona: Azure replica automaticamente datos o aplicaciones entre varias zonas. Azure Storage ZRS (Zone-Redundant Storage) es el ejemplo principal. Servicios zonales: Colocas recursos directamente en una zona especifica. Poner una VM en cada una de las zonas 1, 2 y 3, por ejemplo, asegura que el servicio continue incluso si una zona cae.
Pares de regiones (Region Pairs)
Piensa en centros logisticos gemelos. El centro de Madrid y el centro de Barcelona estan oficialmente emparejados. Si un desastre a gran escala (terremoto, inundacion) golpea Madrid, el centro de Barcelona asume automaticamente el servicio. Ambos centros monitorean constantemente el estado del otro. Eso es un par de regiones.
Principales pares de regiones
| Region 1 | Region 2 | |---------|---------| | Korea Central (Seoul) | Korea South (Busan) | | East US | West US | | North Europe | West Europe | | East Asia | Southeast Asia | | Japan East | Japan West |
Caracteristicas importantes de los pares de regiones
Las dos regiones estan al menos 300 km de distancia dentro de la misma area geografica (mismo pais o paises adyacentes). Un desastre a gran escala activa la conmutacion automatica por error de una region a la otra. Cuando Azure lanza actualizaciones de plataforma, nunca actualiza ambas regiones de un par al mismo tiempo. Actualiza una primero y solo actualiza la otra si la primera tiene exito. Esto evita interrupciones totales del servicio durante las actualizaciones. La replicacion de datos permanece dentro del mismo pais o paises adyacentes, respetando las regulaciones de soberania de datos.
Zonas de disponibilidad vs. Pares de regiones
| | Zonas de disponibilidad | Pares de regiones | |--|----------------------|-----------------| | Alcance | Dentro de la misma region | Regiones diferentes (cientos de km) | | Distancia | Pocos km | Al menos 300 km | | Protege contra | Fallo de un solo centro de datos | Desastres que afectan a toda una region | | Conteo tipico | 3 por region | 1 par por region | | Estado activo | Ambas zonas activas simultaneamente | Una en espera, se activa ante fallo |
Regiones soberanas (Sovereign Regions)
Son regiones de proposito especial fisica y logicamente aisladas de las regiones comerciales estandar de Azure. Existen para cumplir con requisitos gubernamentales o reglamentarios especificos.
Azure Government: Reservado exclusivamente para agencias gubernamentales federales, estatales y locales de EE.UU. y sus socios. Accesible solo desde dentro de Estados Unidos; completamente inaccesible con una cuenta estandar de Azure. Cumple con los estandares de seguridad FedRAMP y DoD del gobierno de EE.UU. Azure China: Un entorno aislado que opera completamente dentro de China, segun lo exige la ley china. Operado por 21Vianet, no por Microsoft.
En el examen, siempre que se mencione "un entorno especial de Azure para las agencias gubernamentales de un pais especifico", una region soberana es la respuesta.
Estructura logica — La analogia del sistema de archivo empresarial
Si la infraestructura fisica es "donde estan los servidores de Azure", la estructura logica es "como se gestionan los recursos de Azure". La forma en que una empresa organiza el archivo de documentos facilita entenderlo.
Un Recurso es una hoja de papel. Una VM, una base de datos, una red — cada una es un recurso.
Un Grupo de recursos es una carpeta de archivo. Los documentos relacionados van en una carpeta. Por ejemplo, una carpeta "proyecto web" contiene la VM del servidor web, la base de datos y el balanceador de carga.
Una Suscripcion es un cajon de archivo. Un cajon genera una factura. Usar cajones diferentes por departamento separa los costos departamentales.
Un Grupo de gestion es el archivador completo. Multiples cajones (suscripciones) se agrupan en un archivador y la misma politica de seguridad se aplica a todos a la vez.
!La jerarquía de recursos de Azure
Jerarquia completa
Grupos de recursos (Resource Groups)
Un grupo de recursos es un contenedor que agrupa recursos de Azure relacionados como una unica unidad de gestion. Cada recurso de Azure debe pertenecer a exactamente un grupo de recursos.
Caracteristicas importantes de los grupos de recursos
Cada recurso de Azure puede pertenecer a exactamente un grupo de recursos; no puede estar en dos grupos al mismo tiempo. Eliminar un grupo de recursos elimina todos los recursos dentro de el. Esta es una funcion potente, pero usarla incorrectamente puede causar perdida de datos. El grupo de recursos en si no genera costos. Solo los recursos dentro de el generan cargos. Los recursos de un grupo de recursos pueden comunicarse libremente con recursos de otro grupo de recursos. Los recursos pueden moverse a un grupo de recursos diferente (aunque algunos tipos de recursos tienen restricciones de movimiento). Se pueden aplicar etiquetas (tags) a los grupos de recursos para rastrear costos o categorizar recursos.
Patrones comunes de organizacion de grupos de recursos
Por proyecto: "ProyectoA-Dev", "ProyectoA-Prod" Por entorno: "Dev-GrupoRecursos", "Test-GrupoRecursos", "Prod-GrupoRecursos" Por departamento: "Marketing-GrupoRecursos", "Ingenieria-GrupoRecursos" Por ciclo de vida: Agrupar recursos que se eliminaran juntos al mismo tiempo
Suscripciones (Subscriptions)
Una suscripcion es la unidad contractual y de facturacion para usar los servicios de Azure. Cada recurso de Azure debe pertenecer a exactamente una suscripcion. Las suscripciones tambien sirven como limites de control de acceso.
Roles clave de una suscripcion
Limite de facturacion: Se genera una factura separada para cada suscripcion. Separar suscripciones por departamento da visibilidad precisa de los costos de nube de cada departamento. Limite de control de acceso: Azure RBAC (Control de Acceso Basado en Roles) se puede aplicar a nivel de suscripcion. Los equipos que deben estar aislados entre si usan suscripciones separadas. Limites de recursos: Cada suscripcion tiene limites de creacion de recursos. Por ejemplo, una suscripcion tiene por defecto un maximo de 20,000 VMs. Si se alcanza un limite, puedes crear una nueva suscripcion o solicitar un aumento.