En la arquitectura moderna de infraestructura en la nube, garantizar la alta disponibilidad de las aplicaciones es crítico. Uno de los conceptos fundamentales para lograr esto es comprender qué es un Fault Domain o Dominio de Fallos. En este artículo, te explicaré en detalle qué es, cómo funciona y por qué es esencial para diseñar sistemas resilientes.
#¿Qué es un Fault Domain?
Un Fault Domain (Dominio de Fallos) es un grupo lógico de hardware físico en un centro de datos que comparte una fuente de alimentación común y un switch de red común. En términos sencillos, un fault domain representa típicamente un bastidor (rack) de servidores dentro de un data center.
Todos los servidores dentro de un fault domain están ubicados físicamente en el mismo lugar y comparten la misma infraestructura de energía y conectividad de red. Si algo falla en esa infraestructura compartida —como un apagón, un fallo del switch de red o un problema de refrigeración— todos los sistemas en ese fault domain se ven afectados simultáneamente.
El objetivo fundamental de entender los fault domains es eliminar puntos únicos de fallo en tu arquitectura. Cuando distribuyes tus aplicaciones y servicios críticos a través de múltiples fault domains, proteges tu sistema de fallos de infraestructura que afectarían a todos los componentes si estuvieran ubicados en el mismo lugar.
#Componentes de un Fault Domain
Cada fault domain típicamente incluye:
- Servidores físicos (hosts): Las máquinas que ejecutan tus máquinas virtuales
- Fuente de alimentación (Power Supply): Sistema de energía que alimenta todos los servidores en el rack
- Switch de red: Dispositivo de red que conecta todos los servidores dentro del rack
- Sistema de refrigeración: Infraestructura de enfriamiento local para el rack
- Infraestructura de almacenamiento: Almacenamiento compartido si aplica
Cuando ocurre una falla en cualquiera de estos componentes compartidos, todos los servidores en ese fault domain se ven afectados. Por eso es crítico distribuir tu carga de trabajo a través de múltiples dominios de fallos.
#¿Cómo Funciona un Fault Domain?
#Distribución Automática en Azure
En Azure, cuando creas máquinas virtuales dentro de un Availability Set, el platform de Azure automáticamente distribuye tus máquinas virtuales a través de múltiples fault domains. Esto significa que no necesitas preocuparte manualmente por la colocación.
Por ejemplo, si creas 3 máquinas virtuales en un Availability Set en una región que soporta 3 fault domains:
- VM 1 → Fault Domain 1 (Rack A)
- VM 2 → Fault Domain 2 (Rack B)
- VM 3 → Fault Domain 3 (Rack C)
Si el Rack A experimenta un apagón, solo la VM 1 se ve afectada. Las máquinas virtuales 2 y 3 continúan funcionando sin interrupciones porque están en racks diferentes con sus propias fuentes de alimentación y switches de red.
#Límites de Fault Domains
La mayoría de proveedores cloud ofrecen los siguientes límites:
- Azure Availability Sets: Mínimo 2, Máximo 3 fault domains en la mayoría de regiones
- Azure Virtual Machine Scale Sets: Hasta 5 fault domains por defecto, configurable entre 1 y 3
- Oracle Cloud Infrastructure (OCI): Cada Availability Domain contiene 3 Fault Domains
- AWS: Las Availability Zones actúan como failure domains
#Fault Domain vs Availability Zone: ¿Cuál es la Diferencia?
Es crucial entender la diferencia entre estos dos conceptos, ya que a menudo se confunden:
| Aspecto | Fault Domain | Availability Zone |
|---|---|---|
| Ubicación | Dentro de un datacenter (mismo edificio) | Múltiples datacenters en una región (hasta 100 km de distancia) |
| Aislamiento físico | Un rack o grupo de racks | Datacenters completamente separados con poder, refrigeración y redes independientes |
| Nivel de SLA | Protección a nivel de rack/infraestructura local | 99.99% (Protección de datacenter completo) |
| Latencia de red | Muy baja (< 1ms) | Baja (< 5ms típicamente) |
| Costo de transferencia de datos | Sin costo | Sin costo dentro de región (en AWS/Azure/GCP) |
Una Availability Zone en Azure es una combinación de un fault domain y un update domain. Esto significa que las zonas de disponibilidad ofrecen una protección más fuerte que los fault domains, ya que incluyen aislamiento de toda la infraestructura, no solo de un rack.
#Tipos de Fallos que Protegen los Fault Domains
Los fault domains te protegen contra los siguientes tipos de fallos:
#Fallos de Poder (Power Failures)
Si una fuente de alimentación falla en el Rack A, todos los servidores en ese rack pierden energía. Sin embargo, si tus máquinas virtuales están distribuidas en múltiples fault domains, los servidores en otros racks con sus propias fuentes de alimentación continuarán funcionando.
#Fallos de Red (Network Failures)
Un fallo en el switch principal del Rack B podría desconectar todos los servidores de ese rack. Con la distribución en múltiples fault domains, tu tráfico de red puede ser redirigido a través de otros switches en otros racks.
#Fallos de Hardware
Cuando el hardware en un rack necesita mantenimiento o falla, solo los servidores en ese fault domain se ven afectados. Si tus sistemas críticos están distribuidos en múltiples dominios de fallos, tu aplicación continúa funcionando.
#Fallos de Refrigeración
Un problema en el sistema de refrigeración de un rack podría causar que los servidores se sobrecalienten. Nuevamente, si tienes redundancia en múltiples fault domains, tu servicio permanece disponible.
#Ejemplos Prácticos de Fault Domains
#Ejemplo en Azure
Imagina que estás ejecutando una aplicación web con una arquitectura de 3 capas: web server, application server y database. Quieres alta disponibilidad:
Configuración deficiente (evitar):
Fault Domain 1 (Rack A): - Web Server - Application Server - Database Server - Load Balancer
En esta configuración, si el Rack A falla, TODA tu aplicación se cae. Este es un punto único de fallo.
Configuración recomendada:
Fault Domain 1 (Rack A): - Web Server 1 - Application Server 1 - Database Server (Primary) Fault Domain 2 (Rack B): - Web Server 2 - Application Server 2 - Database Server (Replica) Fault Domain 3 (Rack C): - Web Server 3 - Application Server 3 - Database Server (Replica) Load Balancer (distribuye tráfico entre FD1, FD2, FD3)
En esta configuración, si el Rack A falla, los Racks B y C continúan sirviendo a los usuarios. El database ha sido replicado en los otros racks, por lo que no hay pérdida de datos.
#Ejemplo en Oracle Cloud Infrastructure (OCI)
En OCI, cada Availability Domain contiene 3 Fault Domains. Supongamos que tienes una aplicación de e-commerce:
Availability Domain: us-phoenix-1 Fault Domain 1: Instancia de aplicación + Almacenamiento local Fault Domain 2: Instancia de aplicación + Almacenamiento local Fault Domain 3: Instancia de aplicación + Almacenamiento local
Cuando despliegas una máquina virtual, puedes especificar en qué Fault Domain quieres que se coloque la instancia. OCI asegura que si una instancia falla en FD1, las instancias en FD2 y FD3 continúan ejecutándose.
#Ejemplo en VMware vSAN
Clúster vSAN con 8 hosts en 4 racks: Fault Domain 1 (Rack A): Host 1, Host 2 Fault Domain 2 (Rack B): Host 3, Host 4 Fault Domain 3 (Rack C): Host 5, Host 6 Fault Domain 4 (Rack D): Host 7, Host 8
vSAN ajusta dónde coloca datos para mantener niveles de resiliencia de acuerdo con la política de almacenamiento prescrita para cada objeto. Si un rack falla, los datos se reconstruyen a través de los otros racks.
#Fault Domains en Kubernetes y GKE
En Google Kubernetes Engine (GKE), los nodos de un clúster regional se distribuyen automáticamente a través de múltiples zonas de una región. Esto proporciona tolerancia a fallos de zona.
En AWS, un failure domain corresponde a una Availability Zone dentro de una región. Kubernetes automáticamente distribuye los pods a través de múltiples zonas para asegurar resiliencia.
Cuando usas GKE con configuración regional, el control plane se ejecuta en múltiples zonas, asegurando que tu clúster pueda tolerar la pérdida de una zona completa.
#Mejores Prácticas para Usar Fault Domains
#1. Distribuye tu aplicación en múltiples Fault Domains
Nunca coloque todos los componentes críticos en un único fault domain. Para máxima resiliencia, distribuye a través de al menos 2-3 fault domains.
#2. Usa Availability Sets o Availability Zones combinadas con Fault Domains
#3. Implementa Load Balancers
Usa load balancers para distribuir tráfico a través de múltiples instancias ubicadas en diferentes fault domains. En AWS, usa Application Load Balancers configurados para múltiples availability zones.
#4. Configura Replicación de Datos
Asegúrate de que tus bases de datos estén replicadas a través de múltiples fault domains. Si una réplica falla, otras pueden tomar el relevo.
#5. Planifica la Capacidad
#6. Monitorea la Salud de cada Fault Domain
Implementa monitoreo para detectar cuando un fault domain experimenta problemas. En Windows Server failover clusters, utiliza el Health Service para proporcionar alertas más útiles.
#Fault Domains y Alta Disponibilidad (HA)
Los fault domains son un componente crítico de cualquier estrategia de alta disponibilidad. Cuando combinas fault domains con otros patrones de HA como:
- Replicación de datos
- Load balancing
- Auto-failover
- Health checks
Logras una arquitectura altamente resiliente que puede tolerar múltiples tipos de fallos simultáneamente.
#Ventajas y Desventajas
#Ventajas
- Eliminación de puntos únicos de fallo: Protege contra fallos de infraestructura compartida
- Bajo costo adicional: En OCI, los fault domains están disponibles sin costo adicional en todas las regiones públicas
- Baja latencia: A diferencia de las Availability Zones, los fault domains están en el mismo datacenter, manteniendo latencia muy baja
- Simplicidad de implementación: La mayoría de proveedores cloud automatizan la distribución
#Desventajas
- Protección limitada: No protege contra fallos de datacenter completo (usa Availability Zones para eso)
- Complejidad arquitectónica: Requiere diseño cuidadoso para máxima resiliencia
- Límite de fault domains: Típicamente solo 2-3 disponibles, limitando opciones de distribución