Risposta.

L'architettura ridondante è necessaria per garantire il funzionamento continuo dei sistemi IT anche in caso di guasti di singoli componenti. Il principio principale è eliminare i punti unici di guasto grazie alla ridondanza, al bilanciamento del carico e al ripristino automatico.

Schema classico di un sistema ridondante include cluster di server, database replicati, bilanciatori di carico e sistemi di monitoraggio. Per grandi sistemi viene applicata la geodistribuzione, cioè la collocazione delle repliche in diversi data center.

Esempio di configurazione nginx con più upstream:

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
    least_conn;
}
server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://backend;
    }
}

Caratteristiche chiave:

• Utilizzo di cluster con rilevamento automatico dei guasti
• Bilanciamento del traffico e spostamento del carico manuale/automatico
• Monitoraggio e allerta obbligatori per un rapido ripristino

Domande insidiose.

Se il database è replicato, si può sempre garantire la coerenza dei dati tra le repliche?

No, la coerenza dipende dal modello di replica scelto (forte/coerenza eventuale). Ad esempio, per la coerenza eventuale i ritardi di sincronizzazione possono portare alla presenza di dati "obsoleti" su alcune repliche.

Può il bilanciatore di carico risolvere autonomamente il problema di indisponibilità del backend?

No, il bilanciatore può solo escludere il server non funzionante dal pool, ma non può ripararlo. Per il ripristino automatico si utilizzano servizi aggiuntivi (ad esempio, un sistema di orchestrazione come Kubernetes).

È sufficiente semplicemente configurare un cluster di server per la ridondanza?

No, è anche importante monitorare la ridondanza dell'infrastruttura di rete, dello storage e di altri componenti dello stack. Errori nella pianificazione di qualsiasi parte possono mettere a rischio l'intero sistema.