Documentazione dell'infrastruttura Oracle Cloud

High Availability

I sistemi ad alta disponibilità (HA) sono progettati per garantire il massimo potenziale di uptime e accessibilità.

Le applicazioni aziendali sono fondamentali per le operazioni aziendali quotidiane e devono essere disponibili. C'è un'aspettativa che questi sistemi funzionino sempre e non ci saranno mai tempi di inattività. Anche se è impossibile escludere completamente i tempi di inattività, è possibile ridurre al minimo gli impatti negativi dei tempi di inattività garantendo che le applicazioni abbiano HA. 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. Oracle Cloud Infrastructure (OCI) offre funzionalità HA e best practice di topologia cloud affidabili e resilienti che ti consentono di creare applicazioni aziendali ad alta disponibilità.

Poiché le architetture multilivello o a tre livelli sono comuni nelle applicazioni aziendali on-premise tradizionali, utilizziamo un'applicazione aziendale a tre livelli di esempio per mostrare come utilizzare le funzionalità OCI HA e le best practice di topologia cloud affidabili e resilienti per rendere l'applicazione HA. Il diagramma riportato di seguito mostra un'applicazione enterprise di esempio in una configurazione HA a area singola.

Esempio di applicazione aziendale in una configurazione High Availability di un'unica area.

Queste informazioni non coprono gli aspetti della connettività da ambienti on premise a OCI o di disaster recovery (DR) dell'infrastruttura.

Concetti HA

Quando la tua infrastruttura è configurata per fornire una disponibilità quasi a tempo pieno, si tratta di un sistema HA.

Per progettare un'architettura ad alta disponibilità, considerare i seguenti elementi chiave:

  • Ridondanza: ogni risorsa dispone di almeno una risorsa simile pronta a intervenire e a subentrare? Si noti che in ogni livello mostrato nel diagramma, le risorse hanno sempre un database primario e uno in standby e le risorse si trovano in domini di disponibilità e di errore diversi per evitare singoli punti di errore (SPOF, Single Point of Failure).
  • Monitoraggio: le risorse primarie funzionano come previsto? In caso contrario, a che punto subentra la risorsa di backup per la risorsa primaria?
  • Failover: quando vengono soddisfatti i criteri per attivare uno switch da primario a standby, lo standby è pronto?

Il raggiungimento di HA richiede che un sistema rappresenti tutti questi elementi. Sebbene l'alta disponibilità possa essere raggiunta a molti livelli diversi (incluso il livello di applicazione e il livello di infrastruttura cloud), questa sezione si concentra sul livello di infrastruttura cloud. Per ulteriori informazioni, vedere Informazioni sull'architettura di una topologia cloud ad alta disponibilità.

Scegliere un approccio HA

Alcune applicazioni sono più critiche di altre. Utilizzare l'albero decisionale riportato di seguito per decidere quali funzionalità OCI HA utilizzare durante la distribuzione di applicazioni enterprise su OCI a più livelli.

Albero decisionale per decidere quali funzionalità di alta disponibilità OCI utilizzare durante la distribuzione di applicazioni aziendali su più livelli.

Per la nostra applicazione aziendale di esempio, abbiamo bisogno di HA e per essere in grado di sopravvivere a un'indisponibilità del dominio di disponibilità. Inoltre, dobbiamo essere in grado di sopravvivere a un'interruzione regionale, ma possiamo gestire alcuni tempi di inattività se una regione ne è colpita. Per questi motivi abbiamo scelto una distribuzione attiva/passiva in più aree. Gli aspetti relativi alla distribuzione passiva sono trattati in Disaster Recovery.

Misurazione HA

L'alta disponibilità è la capacità di un sistema di soddisfare un livello continuo di prestazioni operative o tempi di attività per un determinato periodo di tempo.

La disponibilità è solitamente espressa come percentuale del tempo di attività in un anno, spesso descritto in termini di "nove". La tabella seguente mostra i livelli di disponibilità e il tempo di inattività associato di ciascun livello.

Disponibilità % Disponibilità (nette) Tempo di inattività all'anno Tempo di inattività al mese Tempo di inattività alla settimana Tempo di inattività al giorno
90% Uno nove 36.53 giorni 73.05 ore 16.80 ore 2.40 ore
99% Due nove 3.65 giorni 7.31 ore 1.68 ore 14.40 minuti
99,9% Tre nove 8.77 ore 43.83 minuti 10.08 minuti 1.44 minuti
99,99% Quattro nove 52.60 minuti 4.38 minuti 1.01 minuti 8.64 secondi
99,999% Cinque nove 5.26 minuti 26.30 secondi 6.05 secondi 864.00 millisecondi
100% Sei nove 31.56 secondi 2.63 secondi 604.80 millisecondi 86.40 millisecondi
100% Sette nove 3.16 secondi 262.98 millisecondi 60.48 millisecondi 8.64 millisecondi
100% Otto nove 315.58 millisecondi 26.30 millisecondi 6.05 millisecondi 864.00 microsecondi
100% Nove nove 31.56 millisecondi 2.63 millisecondi 604.80 microsecondi 86.40 microsecondi

Ogni servizio Oracle Cloud Infrastructure in genere ha un service-level agreement (SLA) che definisce la disponibilità prevista di tale servizio. La maggior parte delle soluzioni cloud richiede l'utilizzo di una combinazione di servizi per ottenere l'architettura desiderata per l'implementazione cloud. Quando i servizi vengono utilizzati in combinazione, la disponibilità complessiva del sistema dipende dalla disponibilità di ciascuno dei sottosistemi. Lo SLA complessivo per un sistema con più componenti è denominato SLA composito.

Per calcolare lo SLA composito di un sistema o di un'applicazione, prendere in considerazione tutti i sottosistemi e le modalità di configurazione di tali sistemi. Si consideri ad esempio uno scenario in cui un'applicazione dipende da due sistemi, System A e System B. Ogni sistema ha una disponibilità del 99,9%. I sistemi dipendono in serie, come illustrato nella seguente immagine.

Diagramma di un sistema di esempio con sottosistemi dipendenti in serie.

Se il sistema A o il sistema B non sono disponibili, l'intero sistema non sarà disponibile. Per questo tipo di configurazione di sistema, è possibile calcolare lo SLA composito moltiplicando la disponibilità dei due sistemi: 99,9% × 99,9% = 99,8%. A causa della dipendenza seriale tra i due sistemi, lo SLA composito risultante del 99,8% è inferiore ai singoli SLA per ogni sistema.

considerazioni sulla progettazione HA

Oracle Cloud Infrastructure fornisce gli elementi di base che ti consentono di abilitare HA per la tua infrastruttura.

L'applicazione aziendale di esempio utilizza i servizi all'interno dei concetti OCI di aree, domini di disponibilità e domini di errore. L'uso di più domini di disponibilità e più domini di errore all'interno di ciascuno di tali domini di disponibilità aumenta la ridondanza ed elimina SPOF. Per informazioni generali sulle aree e una lista di risorse disponibili in più aree, all'interno di una singola area o all'interno di un singolo dominio di disponibilità, vedere Aree e domini di disponibilità.

Abbiamo consigliato di rivedere le informazioni pertinenti sulla resilienza dei prodotti OCI e quindi, in base ai prodotti della piattaforma OCI scelti, regolare le architetture per colmare eventuali lacune tra le funzionalità dei prodotti e i relativi requisiti HA.

L'area di origine è l'area in cui Oracle crea la tenancy ed è qui che vengono definite le risorse IAM (Identity and Access Management) dell'organizzazione. A seconda dei requisiti aziendali, è possibile eseguire la sottoscrizione ad altre aree e IAM propaga automaticamente gli aggiornamenti a tutte le aree della tenancy. Per ulteriori informazioni, vedere Gestione delle aree.

Networking

Dopo aver creato la rete di base delle reti cloud virtuali (VCN) e delle subnet, per fornire alta disponibilità è necessario utilizzare il servizio di bilanciamento del carico per distribuire il traffico. Quando un load balancer viene distribuito, utilizza una configurazione HA come mostrato nel diagramma dell'architettura di esempio. Per ulteriori informazioni, vedere Pianifica High Availability per risorse di rete.

Calcolo

Per eliminare SPOF, creare più istanze di computazione distribuite tra domini di errore in ciascuno dei domini di disponibilità. Posiziona le istanze di computazione dietro un load balancer per distribuire il traffico e ottenere HA come mostrato nell'architettura di esempio. Per ulteriori informazioni, vedere Panoramica del servizio di computazione, Best practice per le istanze di computazione e Piano High Availability per le istanze di computazione.

Storage

OCI fornisce un set di servizi di storage (Volume a blocchi, Storage di file e Storage degli oggetti), che puoi configurare per soddisfare i requisiti di un'architettura ad alta disponibilità.

Object Storage è una piattaforma di storage su scala Internet ad alte prestazioni che offre durabilità dei dati affidabile ed efficiente in termini di costi. Lo storage degli oggetti è un servizio regionale ed è disponibile in tutti i domini di disponibilità all'interno di un'area geografica. I dati vengono memorizzati in modalità ridondante su diversi server di storage e in più domini di disponibilità per garantire l'alta disponibilità. Lo storage degli oggetti include anche funzionalità automatiche di autoriparazione e monitoraggio dell'integrità dei dati per migliorarne ulteriormente la durabilità e la disponibilità.

Lo storage di file fornisce un file system di rete di livello Enterprise duraturo, scalabile e sicuro. Utilizza un'architettura resiliente che replica i dati cinque volte in domini di errore diversi, garantendo alta disponibilità e durabilità. Lo storage di file può ridimensionarsi automaticamente per accogliere la crescita di fino a 8 exabyte di dati. È possibile utilizzare le istantanee e le cloni del file system per proteggere i dati da eliminazioni accidentali e per eseguire immediatamente copie dei dati. I cicli di vita degli snapshot possono essere gestiti automaticamente utilizzando la funzione istantanea basata su criteri.

I volumi a blocchi sono durevoli e altamente disponibili memorizzando più copie di dati in modalità ridondante nei server di storage con meccanismi di riparazione integrati. I volumi a blocchi possono essere collegati a una o più virtual machine (VM) e persistono oltre la durata delle virtual machine. I volumi a blocchi migliorano ulteriormente l'alta disponibilità con le funzioni di backup automatici nello storage degli oggetti e clonazione dei volumi.

Per la procedura di creazione delle risorse di storage, vedere Creazione di un volume, Creazione di file system e Gestione dei bucket. Per le procedure ottimali, vedere Pianificare l'alta disponibilità per lo storage.

Database

I database Oracle OCI sono disponibili in più modelli o versioni di implementazione. Ogni modello offre un set crescente di funzionalità HA.

Indipendentemente dal sistema di database utilizzato, ti consigliamo di fare riferimento alla Maximum Availability Architecture (MAA), una serie di best practice sviluppate dai tecnici Oracle da molti anni per l'uso integrato delle tecnologie di alta disponibilità, protezione dei dati e disaster recovery di Oracle.

Servizio Base Database OCI

OCI Base Database Service ti consente di avere il pieno controllo sui tuoi dati sfruttando al contempo le funzionalità di Oracle Database e OCI. Per l'elenco delle edizioni di database supportate e delle forme di computazione di base su cui possono essere distribuite, consulta la documentazione di OCI Base Database Service. Le funzioni HA menzionate si applicano a tutte le versioni del database o alle forme di computazione di base.

L'edizione Enterprise Edition Extreme Performance consente di creare un sistema di database Real Application Cluster (RAC) a due nodi con nodi che si estendono su domini di errore diversi all'interno dello stesso dominio di disponibilità. Ciò garantisce l'alta disponibilità nei seguenti scenari:

  • Protezione dagli errori dei nodi
  • Manutenzione software senza tempi di inattività
  • Modifiche elastiche (CPU, memoria e storage) senza tempi di inattività
  • (Quasi) Manutenzione trasparente non pianificata

Se HA è richiesto nei domini di disponibilità, potresti prendere in considerazione un database in standby passivo abilitato per RAC che esegue il mirroring del sistema di database RAC primario, con i dati replicati tramite Oracle Data Guard. Il failover al standby passivo potrebbe essere manuale con un piccolo tempo di inattività.

Nota: OCI Base Database supporta un massimo di due nodi RAC. Per le versioni di Oracle Database o per nodi RAC superiori a 2, prendi in considerazione OCI Exadata Database on Dedicated Infrastructure (ExaDB-D).

Exadata Database on Dedicated Infrastructure (ExaDB-D)

Exadata offre funzionalità ad alta disponibilità integrate.

Tutte le best practice esistenti con il tuo Exadata on-premise sono applicabili. I concetti descritti per OCI Base Database, ad esempio RAC e Data Guard (per il database in standby), sono applicabili a Exadata Database on Dedicated Infrastructure (ExaDB-D), con i seguenti attributi aggiuntivi:

  • Exadata Database on Dedicated Infrastructure (ExaDB-D) consente più di due nodi RAC, un limite relativo al sistema di Base Database.
  • Scalabilità, performance e disponibilità di Exadata
  • Agilità di Exadata con il numero in continua evoluzione di VM, storage e risorse di computazione
  • Protezione dei dati ed Exadata QoS per le operazioni del database

Exadata prevede il rilevamento immediato degli errori in grado di rilevare nodi del database, server di storage e errori di rete in meno di 2 secondi e riprendere il tempo di attività e le prestazioni del servizio di applicazioni e database.

Consigliamo le configurazioni riportate di seguito per garantire la disponibilità continua delle applicazioni.

  • Utilizzare i servizi di database gestiti da Oracle Clusterware per connettere l'applicazione. Per gli ambienti Oracle Data Guard, utilizzare i servizi basati sui ruoli.
  • Utilizzare la stringa di connessione consigliata con timeout, nuovi tentativi e ritardi integrati, in modo che le connessioni in entrata non visualizzino errori durante le interruzioni.
  • Configurare le connessioni con le notifiche Fast Application Notification.
  • Utilizza Continuità di applicazione o Continuità di applicazione trasparente per riprodurre in tempo le transazioni non sottoposte a commit in modo trasparente dopo gli errori.

Autonomous Database

Per impostazione predefinita, Oracle Autonomous Database (ADB) è altamente disponibile e include una configurazione multi-nodo per la protezione da errori hardware localizzati.

Ogni servizio applicazione ADB risiede in almeno un'istanza di Oracle Real Application Clusters (Oracle RAC), con la possibilità di eseguire il failover su un'altra istanza Oracle RAC disponibile per indisponibilità non pianificate o attività di manutenzione pianificate, consentendo tempi di inattività pari a zero o quasi zero.

I principali aggiornamenti del database sono automatizzati. Inoltre, i tempi di inattività per Oracle Autonomous Database Serverless (ADB-S) sono minimi.

I Service Level Agreement (SLA) di uptime al mese sono del 99,95% (un massimo di 22 minuti di downtime al mese).

ADB-S consente un database locale (tra i domini AD o all'interno dei domini AD per le singole aree AD) e un database in standby remoto aggiuntivo.

Autonomous Data Guard aggiunge un database di standby simmetrico con Oracle Data Guard a un rack Exadata in locale (tra i domini AD o all'interno dei domini AD per le aree con singolo AD) con un database aggiuntivo in un'altra area. I sistemi di database primario e in standby vengono configurati in modo simmetrico per garantire che i livelli di servizio delle prestazioni vengano gestiti dopo le transizioni dei ruoli Data Guard.

Le best practice per la gestione dei tempi di attività delle applicazioni sono descritte qui.

Controllo in corso

Il Monitoraggio consente di monitorare in modo attivo e passivo le risorse cloud per migliorare la disponibilità e garantire livelli di servizio coerenti. Per un esempio, vedere Monitoraggio end-to-end delle applicazioni in esecuzione su Oracle Cloud Infrastructure.

Visualizza altro

Playbook di soluzione:

Architetture di riferimento:

Blog e altre risorse: