Due server applicativi possono condividere la causa di un guasto

Un secondo server applicativo può subentrare a un processo guasto. La possibilità per il cliente di continuare a lavorare dipende però anche dai componenti condivisi. Il prossimo investimento dovrebbe quindi coprire un guasto identificato, invece di aumentare soltanto il numero dei server.

Microsoft raccomanda di considerare la ridondanza di calcolo, dati e rete lungo i flussi critici. Raddoppiare il livello applicativo non risponde ancora alla domanda sul flusso completo.

Rendere visibile il percorso condiviso

Nell’esempio immaginario, i clienti aprono un elenco di progetti. Due istanze applicative su macchine virtuali separate leggono lo stesso database. Davanti si trova un unico bilanciatore di carico gestito dal team. Distribuisce le richieste; qui non si intende un servizio di accesso gestito e ridondante al proprio interno. I dati di sessione necessari per proseguire non sono conservati soltanto su un’istanza applicativa.

Gli identificativi della tabella appartengono solo a questo esempio. Inizialmente non esiste un sostituto del database o del bilanciatore. La tabella descrive effetti attesi, non una disponibilità misurata.

Quale guasto può coprire la seconda istanza

Anche il primo caso è un’aspettativa da verificare. Se la macchina rimasta è sovraccarica o l’instradamento non funziona, la sua sola presenza non basta. Due VM possono anche condividere sede, alimentazione o altre infrastrutture; i domini di guasto effettivi devono corrispondere al requisito.

Affrontare il livello dati condiviso

Se l’elenco deve restare disponibile durante un guasto del database, il livello dati richiede un approccio adatto a disponibilità e failover. Vanno chiariti perdita di dati accettabile, coerenza e comportamento delle scritture in corso. Anche un secondo processo di database non dimostra da solo una prosecuzione sicura.

Microsoft distingue le repliche in esecuzione dalle copie di backup riferite a un momento preciso. Un backup serve al ripristino; non è automaticamente un database sostitutivo già in esecuzione e subito disponibile. La replica non sostituisce un ripristino verificato dopo una modifica involontaria dei dati. Le misure necessarie dipendono dall’obiettivo aziendale.

Decidere dal flusso utente interessato

L’analisi dei guasti di Microsoft segue ogni flusso critico e le sue dipendenze interne ed esterne. Per il nostro esempio, i tre casi della tabella andrebbero verificati separatamente in un ambiente autorizzato. Vanno registrati rilevamento, comportamento durante il caricamento dell’elenco, ripresa e ruolo responsabile.

Se un percorso di ripristino concordato copre adeguatamente un’interruzione del database, l’istanza applicativa aggiuntiva può restare utile per guasti di processo o manutenzione. Se l’attività richiede continuità anche durante guasti del database o dell’accesso, queste lacune restano. Dal numero di macchine non si può ricavare una percentuale di disponibilità.

Fonti

• Microsoft — Architecture strategies for designing for redundancy

• Microsoft — Architecture strategies for performing failure mode analysis

• Microsoft — Redundancy, replication, and backup