5.6. Alta disponibilidad¶

Un siguiente nivel para mejorar el rendimiento sería la ALTA DISPONIBILIDAD mediante REDUNDANCIA de servidores. En estos casos tenemos un servidor intermedio(proxy inverso) que puede actuar, por ejemplo, como:

Balanceador de carga: Reparte las peticiones entre varios servidores web que contienen la misma información, de forma que si uno de ellos falla, el servicio sigue funcionando sin problemas. Este es el esquema más habitual en grandes sitios web con mucho tráfico.

Proxy cache: Almacena en caché las respuestas de los servidores web para acelerar la entrega de contenido a l@s usuari@s y reducir la carga en los servidores backend.

Codigo fuente web en unidad compartida: Los servidores web pueden acceder a una unidad de red donde se encuentra el código fuente de la web, de forma que todos los servidores web acceden a la misma información y no es necesario replicarla en cada uno de ellos. Alternativas de almacenamiento en red: NFS, SMB, EFS (AWS). Esta unidad se puede proteger mediante RAID, LVM o copias de seguridad periódicas.

Base de datos replicada: Los servidores web pueden conectarse a una base de datos que se encuentra replicada en varios nodos, de forma que si uno de ellos falla, otro nodo puede asumir su función sin pérdida de datos. Alternativas: Replicación maestra-esclavo, clústeres de bases de datos, etc…

El objetivo es repartir las peticiones entre varios servidores web que contienen la misma información, de forma que si uno de ellos falla, el servicio Tenemos diferentes alternativas si queremos configurar un escenario de redundancia (La mayoría de las webs que visitamos en realidad trabajan con estos esquemas)

Apache pueden configurarse para actuar como servidor intermedio (documentación oficial).

En el caso de NginX, es uno de los puntos fuertes del programa (guía en la documentación de CLOUDING.IO).

Existe SW específico que nos pueden ofrecer más alternativas de configuración (una de las más populares es HAPROXY).

5.6.1. Ejemplo HA¶

Un ejemplo completo de alta disponibilidad, incluyendo balanceo de carga, proxy cache, nodos web, almacenamiento en red y base de datos replicada podría ser el siguiente:

        graph TD


    subgraph LB_Layer [Capa de Balanceo - HA]
        LB1[🔥 Balanceador Activo - Apache/Nginx/HAProxy]

    end

    subgraph Cache_Layer [⚡ Aceleración]
        LB1 --> Proxy[🚀 Proxy Cache: Varnish/Nginx]
    end

    subgraph Web_Layer [💻 Nodos de Aplicación]
        Proxy --> Web1[🖥️ Web Srv A - Apache/NginX]
        Proxy --> Web2[🖥️ Web Srv B - Apache/NginX]
    end

        Web1 & Web2 --> NFS[[📁 Unidad Red: NFS/SMB/EFS]]
        NFS --> Backup/RAID/LVM

        Web1 & Web2 --> DB_Master[(👑 DB Master - Escritura)]
        DB_Master -- 🔄 Replicación --> DB_Slave[(🥈 DB Slave - Lectura)]


    %% Estilos para que se vea genial
    style LB1 fill:#f96,stroke:#333
    style Proxy fill:#aaffcc,stroke:#333
    style NFS fill:#ccffaa,stroke:#333
    style DB_Master fill:#3498db,color:#fff
    style DB_Slave fill:#5dade2,color:#fff

Importante

¿Te atreverías a montar tu primer balanceador de carga? Una buena manera para comenzar podría incluir la combinación de:

Una instancia EC2 ejecutando un balanceador de carga HAProxy.

Varias instancias EC2 ejecutando Nginx como servidores web backend.

Una unidad EFS para compartir el código web entre los servidores backend. Amazon Elastic File System (Amazon EFS) es, en pocas palabras, un sistema de archivos en la nube que puedes compartir entre varios servidores al mismo tiempo.

Finalmente automatizar el despliegue de todo el entorno con Terraform. Algo similar a lo que indica en https://registry.terraform.io/modules/stephenharris/efs-mount/aws/latest.

Lograr acceder a tu unidad EFS mediante un tunel SSH(ssh forwarding) para poder subir tu código web a la unidad de red desde tu máquina local.