Affidabilità estrema
Utilizza i principi di alta disponibilità e recupero da errori irreversibili per progettare un'architettura cloud di estrema affidabilità.
I sistemi HA (High Availability) sono progettati per garantire il massimo potenziale di uptime e accessibilità. Per garantire l'alta disponibilità, eliminare singoli punti di errore in modo che, anche in caso di guasto dei componenti, l'applicazione rimanga in esecuzione e disponibile.
Un piano di disaster recovery (DR) ben organizzato consente di recuperare rapidamente da situazioni catastrofiche e di continuare a fornire servizi ai tuoi utenti. DR è il processo di preparazione e recupero da un disastro. Un disastro può essere qualsiasi evento che mette a rischio le tue applicazioni, dalle interruzioni della rete ai guasti delle apparecchiature e delle applicazioni fino alle catastrofi naturali. Per progettare il DR, distribuisci le applicazioni mission-critical in più aree e utilizza la replica asincrona in tutte le aree. Pianifica il recupero da errori irreversibili in tutti i livelli dello stack, inclusi networking, computazione, storage degli oggetti, database e monitoraggio.
Suggerimenti sull'architettura per un'estrema affidabilità
Raccomandiamo un approccio graduale per un'estrema affidabilità. Nella prima fase, implementa un'architettura che fornisce funzionalità HA sfruttando i domini di errore all'interno di un dominio di disponibilità. Se è necessaria una maggiore resilienza, nella seconda fase, implementa un'architettura che si estende su più aree.
Per ulteriori informazioni sulle aree, sui domini di disponibilità e sui domini di errore, vedere Aree e domini di disponibilità.
Fase 1: distribuire le istanze tra i domini di errore
I sistemi ad alta disponibilità sono progettati per evitare singoli punti di guasto. Uno dei principi chiave per la progettazione di un sistema High Availability consiste nel distribuire le istanze tra più domini di errore. Sfruttando correttamente i domini di errore, puoi aumentare la disponibilità delle applicazioni in esecuzione su Oracle Cloud Infrastructure.
L'architettura dell'applicazione determina se separare o raggruppare le istanze utilizzando i domini di errore.
Scenario A: architettura applicativa ad alta disponibilità
In questo scenario si dispone di un'applicazione ad alta disponibilità, ad esempio due server Web e un database in cluster. In questo scenario, è necessario raggruppare un server Web e un nodo di database in un dominio di errore e l'altra metà di ogni coppia in un altro dominio di errore. Questo posizionamento garantisce che un errore di qualsiasi dominio di errore non provochi un'indisponibilità per l'applicazione.
Scenario B: server Web singolo e architettura dell'istanza di database
In questo scenario, l'architettura dell'applicazione non è ad alta disponibilità, ad esempio si dispone di un server Web e di un'istanza di database. In questo scenario, sia il server Web che l'istanza di database devono essere posizionati nello stesso dominio di errore per ridurre al minimo le interruzioni del cliente. Questo posizionamento garantisce che l'applicazione sia interessata solo dall'errore di tale singolo dominio di errore, garantendo nel complesso una maggiore disponibilità dell'applicazione.
SLA composti
Quando i servizi vengono utilizzati in combinazione, la disponibilità complessiva del sistema dipende dalla disponibilità di ciascuno dei sottosistemi. Per massimizzare la disponibilità di un sistema con più sottocomponenti, è necessario ridurre al minimo le dipendenze che i sottocomponenti hanno l'uno sull'altro. Ciò significa che, a seconda dell'architettura dell'applicazione, potresti ottenere la massima affidabilità per una determinata quantità di sforzi ingegneristici sfruttando i domini di errore all'interno di un dominio di disponibilità, anziché estenderli tra le tue risorse nei domini di disponibilità.
Fase 2: distribuzione delle risorse in più aree
Per massimizzare la resilienza dei carichi di lavoro, distribuisci i carichi di lavoro cloud in più aree geografiche anziché in più domini di disponibilità.
La distribuzione in più aree consente di ridurre al minimo i rischi associati a un'indisponibilità regionale, poiché un'indisponibilità regionale può influire su tutti i domini di disponibilità nell'area. L'implementazione in più aree inoltre massimizza il valore dell'impegno ingegneristico che investi nel porting dei tuoi carichi di lavoro in più data center.
Scenario C: architettura a più aree
In questo scenario, l'architettura replica lo stesso stack in due aree.
Per fornire un'origine dati coerente in entrambe le aree, utilizzare funzionalità di replica come GoldenGate per il livello di dati, Autonomous Data Guard per il livello di database e criteri di replica dello storage degli oggetti nel bucket di origine che identificano l'area e il bucket in cui eseguire la replica.
Per il front-end e il livello di applicazione, creare un load balancer e configurare le funzionalità di controllo dello stato sulle risorse backend distribuite tra domini di errore in entrambe le aree. Ogni volta che si distribuisce una nuova applicazione in produzione, distribuire l'applicazione in istanze in entrambe le aree.
Visualizza altro
documentazione: