Diseño de infraestructura

Diseño de dominios de fallo en AWS - El mecanismo de disponibilidad protegido por la estructura de 3 capas AZ, región y partición

Explicamos por qué la infraestructura de AWS está diseñada en 3 capas: AZ (aislamiento de fallos), región (separación geográfica) y partición (separación política), y hasta dónde se propagan los fallos en cada capa con ejemplos concretos.

約 5 分で読めます

Qué es un dominio de fallo

Un dominio de fallo (Fault Domain) es el alcance que afecta un único fallo. Cuántos servidores se detienen si se corta un cable de alimentación, cuántos servidores pierden comunicación si falla un switch de red, cuántos servidores se ven afectados si un edificio del centro de datos sufre un corte eléctrico. Estos alcances de impacto son los dominios de fallo. La infraestructura de AWS está diseñada con dominios de fallo en 3 capas jerárquicas. El dominio de fallo más pequeño es la AZ (Availability Zone), que aísla los fallos de un grupo de centros de datos. El dominio intermedio es la región, que aísla los fallos de ubicaciones geográficamente distantes. El dominio más grande es la partición, que aísla los fallos por razones políticas y legales.

Aislamiento de fallos en AZ - Independencia de energía, refrigeración y red

La AZ es la unidad mínima de aislamiento de fallos de AWS. Cada AZ está compuesta por uno o más centros de datos, con sistemas de energía, refrigeración y conexiones de red completamente independientes. Las AZ dentro de la misma región están conectadas por redes dedicadas de alto ancho de banda y baja latencia, pero están físicamente separadas por decenas de kilómetros o más. Hay casos donde el aislamiento de fallos de AZ funcionó en la práctica. En 2019, ocurrió un fallo eléctrico en una AZ de us-east-1, afectando las instancias EC2 y volúmenes EBS dentro de esa AZ. Sin embargo, las otras AZ de la misma región continuaron operando normalmente. Los servicios que operaban en configuración multi-AZ continuaron sin interrupción.

Separación geográfica de regiones - Preparación ante desastres naturales y fallos a gran escala

Las regiones son infraestructuras independientes ubicadas en lugares geográficamente distantes. Cada región tiene su propio plano de control (el sistema que gestiona la creación, modificación y eliminación de recursos) y opera independientemente de los planos de control de otras regiones. Este diseño garantiza que un fallo en el plano de control de una región no afecte la gestión de recursos en otras regiones. Sin embargo, algunos servicios tienen planos de control globales. IAM, Route 53 y CloudFront son servicios globales con planos de control concentrados en us-east-1. Durante el fallo de red de us-east-1 en 2021, las operaciones de gestión de IAM se vieron afectadas en todas las regiones, lo que demostró los riesgos de los planos de control globales.

Separación política de particiones

Las particiones de AWS son infraestructuras completamente separadas por razones políticas y legales. Existen 3 particiones: la partición comercial (aws), la partición de China (aws-cn) y la partición GovCloud (aws-us-gov). Cada partición tiene IAM independiente, sistema de facturación independiente y soporte independiente, y el intercambio de recursos o transferencia de datos entre particiones es fundamentalmente imposible. La partición de China está separada porque la ley china prohíbe la provisión directa de servicios en la nube por empresas extranjeras. Las regiones de China son operadas por empresas asociadas chinas y son completamente independientes de la infraestructura global de AWS.

Diseño de arquitectura consciente de los dominios de fallo

Comprendiendo la estructura de 3 capas de dominios de fallo, se selecciona el diseño según los requisitos de disponibilidad de la carga de trabajo. La configuración de AZ única es adecuada para entornos de desarrollo y pruebas, o procesamiento por lotes donde se tolera el tiempo de inactividad. El costo es mínimo, pero el servicio se detiene ante un fallo de AZ. La configuración multi-AZ es la configuración estándar para entornos de producción. Colocando ALB + Auto Scaling Group en múltiples AZ y configurando RDS en multi-AZ, se puede resistir el fallo de una sola AZ. La mayoría de las cargas de trabajo son suficientes con esta configuración. La configuración multi-región se adopta cuando es necesario resistir el fallo de una región completa. Con las reglas de failover de Route 53 y la replicación entre regiones de S3, se puede construir una arquitectura que continúe el servicio incluso si una región completa se cae. Sin embargo, el costo y la complejidad operativa aumentan significativamente, por lo que se adopta solo cuando los requisitos de negocio lo justifican.

Servicios relacionados

Amazon Route 53Servicio de Sistema de Nombres de Dominio (DNS) y registro de dominios de alta disponibilidadAmazon S3Servicio de almacenamiento de objetos escalable

Artículos relacionados

El diseño de Availability Zones de AWS - La diferencia en confiabilidad que genera la separación física y el aislamiento de fallosExplicamos la filosofía de diseño de las AZ de AWS como grupos de centros de datos físicamente independientes, comparándolas con las zonas de disponibilidad de Azure y GCP, y analizamos la diferencia en madurez del aislamiento de fallos a partir de incidentes reales.Por qué AWS construye regiones allí - Los criterios desconocidos de selección de ubicación de centros de datosExplicamos los criterios de decisión que AWS considera al determinar la ubicación de regiones, como suministro eléctrico, riesgo geopolítico, legislación de soberanía de datos, conectividad de red y riesgo de desastres naturales, con ejemplos concretos de regiones.Las opciones de estrategia DR de AWS - Diseño gradual de recuperación ante desastres desde Pilot Light hasta Multi-SiteExplicamos la amplitud y flexibilidad de las opciones de recuperación ante desastres que ofrece AWS, centrándonos en las estrategias DR de Pilot Light, Warm Standby, Multi-Site Active/Active y Elastic Disaster Recovery.

Más sobre este tema

Por qué Auto Scaling escala rápido hacia afuera y es cauteloso al reducir - Intención de diseño de la lógica de decisión asimétricaExplica la razón del diseño asimétrico de EC2 Auto Scaling que ejecuta el scale-out inmediatamente mientras establece un período de enfriamiento para el scale-in, el mecanismo de prevención de flapping y la lógica interna del Target Tracking Scaling.Infraestructura adaptable a la demanda con AWS Auto Scaling - Diseño y optimización de políticas de escaladoPresenta cómo utilizar los 3 tipos de políticas (Target Tracking, Predictive y Scheduled) y lograr la optimización de costos con instancias Spot mediante Mixed Instances Policy.Principios de sistemas distribuidos aprendidos de las interrupciones de AWS - Arquitecturas transformadas por grandes incidentesUsando como material los informes de incidentes publicados por AWS, como la interrupción de S3 (2017), la interrupción de Kinesis (2020) y la particularidad de us-east-1, explicamos principios de diseño como Shuffle Sharding, Static Stability y Cell-based Architecture.Por qué AWS construye regiones allí - Los criterios desconocidos de selección de ubicación de centros de datosExplicamos los criterios de decisión que AWS considera al determinar la ubicación de regiones, como suministro eléctrico, riesgo geopolítico, legislación de soberanía de datos, conectividad de red y riesgo de desastres naturales, con ejemplos concretos de regiones.Por qué los Availability Zone ID de AWS difieren por cuenta - La intención de diseño detrás del mapeo de AZExplicamos cómo us-east-1a apunta a diferentes AZ físicas por cuenta, por qué se introdujeron los AZ ID (use1-az1), la intención de diseño de distribución uniforme de capacidad y las consideraciones para la especificación de AZ entre cuentas.Infraestructura de computación por lotes - Procesamiento paralelo a gran escala con AWS BatchExplicamos cómo construir procesamiento por lotes a gran escala con AWS Batch. Cubrimos el diseño de colas de trabajos, auto-escalado de entornos de cómputo, optimización de costos con instancias Spot y la construcción de infraestructura de lotes ideal para computación científica y procesamiento de datos a gran escala.Streaming en vivo con calidad broadcast - Construcción de plataforma de distribución a gran escala con AWS Elemental MediaLive y MediaPackageExplicamos cómo construir una plataforma de streaming en vivo con calidad broadcast usando AWS Elemental MediaLive y MediaPackage. Cubrimos transcodificación en tiempo real, DRM, inserción de anuncios y distribución multi-CDN.Construcción de render farm administrado con AWS Deadline Cloud - Migración de renderizado VFX a la nubeExplicamos la construcción de render farms con Deadline Cloud, la programación de trabajos y la optimización de costos mediante instancias Spot.

Artículos y servicios similares

El diseño de Availability Zones de AWS - La diferencia en confiabilidad que genera la separación física y el aislamiento de fallosExplicamos la filosofía de diseño de las AZ de AWS como grupos de centros de datos físicamente independientes, comparándolas con las zonas de disponibilidad de Azure y GCP, y analizamos la diferencia en madurez del aislamiento de fallos a partir de incidentes reales.Por qué los Availability Zone ID de AWS difieren por cuenta - La intención de diseño detrás del mapeo de AZExplicamos cómo us-east-1a apunta a diferentes AZ físicas por cuenta, por qué se introdujeron los AZ ID (use1-az1), la intención de diseño de distribución uniforme de capacidad y las consideraciones para la especificación de AZ entre cuentas.Principios de sistemas distribuidos aprendidos de las interrupciones de AWS - Arquitecturas transformadas por grandes incidentesUsando como material los informes de incidentes publicados por AWS, como la interrupción de S3 (2017), la interrupción de Kinesis (2020) y la particularidad de us-east-1, explicamos principios de diseño como Shuffle Sharding, Static Stability y Cell-based Architecture.Regiones y ubicaciones de borde de AWS - La ventaja física de 33 regiones y más de 600 PoPAnalizamos el significado de que AWS despliegue 33 regiones, más de 100 AZ y más de 600 ubicaciones de borde en el mundo, desde la comparación de puntos de presencia con Azure y GCP y el valor estratégico del sistema de 3 regiones en Japón.Por qué AWS construye regiones allí - Los criterios desconocidos de selección de ubicación de centros de datosExplicamos los criterios de decisión que AWS considera al determinar la ubicación de regiones, como suministro eléctrico, riesgo geopolítico, legislación de soberanía de datos, conectividad de red y riesgo de desastres naturales, con ejemplos concretos de regiones.