Zonas de disponibilidad y puntos únicos de fallo

Una región de AWS se divide en zonas de disponibilidad y Azure hace lo mismo en las regiones que las tienen: grupos de centros de datos separados, con energía, refrigeración y red propias, para que el fallo de uno no arrastre a los otros. Repartir una carga entre zonas protege de ese tipo de fallo: un corte de energía, un incendio, un problema de red en un edificio.

No protege de todo. Si el fallo es de la región entera, las zonas caen juntas en lo que dependan de servicios regionales. Y si el fallo es lógico —alguien borra una base, un despliegue malo rompe la aplicación, un atacante cifra los datos— el borrado o el cifrado se replica a todas las zonas a la vez, porque para el sistema son operaciones válidas. Por eso la disponibilidad y la copia de seguridad son dos controles distintos, y ninguno sustituye al otro.

Un punto único de fallo es un componente cuya caída detiene el servicio porque no hay otro que lo sustituya. En un inventario se reconoce por dos señales juntas: vive en una sola zona y no tiene réplica ni segundo nodo preparado. Una pieza que vive en una zona pero tiene réplica en otra no es un punto único; una pieza gestionada y repartida por el servicio tampoco.

Abre la tabla componentes y recorre la columna de zonas y la de copias o nodos. En la pasarela de Calamar hay un componente que cumple las dos señales a la vez.

Repartir en zonas sirve de poco si lo que sobrevive no alcanza. La cuenta es sencilla: se toma la zona que más instancias tiene, se resta del total, y se compara lo que queda con lo que pide el pico de carga. Si queda menos de lo necesario, la arquitectura soporta la caída de la zona en disponibilidad pero no en capacidad: sigue respondiendo, lento o con errores.

Mira las tablas capacidad_web y carga. El pico de cierre de mes tiene una cifra de instancias necesarias.

Un balanceador tiene un nodo por cada zona que habilitas, y cada nodo recibe una parte del tráfico de los clientes. Con el balanceo entre zonas activo, cada nodo reparte entre todos los destinos de todas las zonas. Con ese balanceo desactivado, cada nodo reparte solo entre los destinos de su propia zona. En el balanceador de aplicación ese balanceo está siempre activo a nivel de balanceador; en el de red viene desactivado por defecto y se puede activar.

La consecuencia práctica es que, con el balanceo entre zonas desactivado, una zona con pocos destinos recibe tanto tráfico como una con muchos, y los destinos de la zona pequeña van saturados mientras los de la grande trabajan poco.

Aplica lo anterior con números. La tabla destinos_de_balanceo trae el balanceador de red del libro mayor, con dos zonas habilitadas, cuántos destinos tiene registrados en cada una y el balanceo entre zonas desactivado. Cada nodo recibe la misma parte del tráfico de los clientes y la reparte a partes iguales entre los destinos de su zona.