Informazioni sulle pratiche di topologia cloud affidabili e resilienti
Applicazioni affidabili sono:
- Resiliente e recuperare con grazia da guasti, e continuano a funzionare con tempi di inattività minimi e perdita di dati prima del recupero completo.
- Altamente disponibile (HA) ed eseguire come progettato in uno stato di salute senza tempi di inattività significativi.
- Protetto dal fallimento della regione attraverso una buona progettazione di disaster recovery (DR).
Capire come questi elementi funzionano insieme, e come influiscono sui costi, è essenziale per costruire un'applicazione affidabile. Può aiutarti a determinare quanto tempo di inattività è accettabile, il costo potenziale per la tua azienda e quali funzioni sono necessarie durante un recupero.
Architetto per affidabilità
Quando si crea un'applicazione cloud, utilizzare le opzioni riportate di seguito per creare affidabilità.
- Definisci i requisiti.
Definire i requisiti di disponibilità e recupero in base ai carichi di lavoro che si stanno portando alle esigenze del cloud e del business.
- Applicare le best practice architettoniche.
Seguire pratiche comprovate, identificare i possibili punti di errore nell'architettura e determinare in che modo l'applicazione risponderà all'errore.
- Test con simulazioni e guasti forzati.
Simula errori, attiva guasti forzati e verifica il rilevamento e il recupero da questi guasti.
- Distribuire le applicazioni in modo coerente.
Rilasciare in produzione utilizzando processi affidabili e ripetibili e automatizzare ove possibile.
- Monitorare lo stato dell'applicazione.
Rileva i guasti, monitora gli indicatori dei potenziali guasti e valuta lo stato delle applicazioni.
- Gestire guasti e disastri.
Identificare quando si verifica un errore e determinare come risolverlo in base alle strategie stabilite.
Definisci requisiti
Definire i requisiti di disponibilità e recupero in base ai carichi di lavoro che si stanno portando alle esigenze del cloud e del business.
Quando si identificano le proprie esigenze aziendali e si abbinano al piano di affidabilità, prendere in considerazione quanto segue:
- Identificare i carichi di lavoro e i relativi requisiti
Un carico di lavoro è una capacità o un task distinto che è logicamente separato da altri carichi di lavoro, in termini di logica aziendale e requisiti di memorizzazione dei dati. Ogni carico di lavoro ha requisiti diversi per disponibilità, scalabilità, coerenza dei dati e disaster recovery.
- Determinare i pattern d'uso
Il modo in cui viene utilizzata un'applicazione svolge un ruolo nei requisiti. Identificare le differenze nei requisiti durante i periodi critici e non critici. Ad esempio, un'applicazione che gestisce l'elaborazione di fine mese non può fallire durante la fine del mese, ma potrebbe gestire l'errore in altri momenti. Per garantire il tempo di attività, è possibile aggiungere componenti aggiuntivi o ridondanza durante i periodi critici e rimuoverli quando non aggiungono più valore.
- Identifica componenti e percorsi critici
Non tutti i componenti del sistema potrebbero essere importanti come altri. Ad esempio, è possibile disporre di un componente facoltativo che aggiunge un valore incrementale, ma che il carico di lavoro possa essere eseguito senza se necessario. Comprendere dove si trovano questi componenti e viceversa dove si trovano le parti critiche del carico di lavoro. Ciò contribuirà a definire l'ambito delle metriche di disponibilità e affidabilità e a pianificare le strategie di recupero in modo da assegnare priorità ai componenti più importanti.
- Identificare le dipendenze esterne e l'effetto dell'errore a valle
Se il carico di lavoro dipende da servizi esterni, un errore in queste dipendenze può influire negativamente sulla disponibilità del carico di lavoro. Implementare metodi di disaccoppiamento dell'integrazione per isolare dagli errori a valle.
- Determina i requisiti di disponibilità del carico di lavoro
L'elevata disponibilità (HA) è normalmente definita in termini di tempo di inattività. Una destinazione HA del 99%, ad esempio, significa che una determinata risorsa può non essere disponibile per 3.65 giorni in un anno. Oracle Cloud Infrastructure (OCI) è progettato per fornire un ambiente altamente disponibile. OCI pubblica uno SLA (Service Level Agreement) per ciascuno dei suoi servizi che descrive gli impegni di Oracle in termini di tempo di attività e connettività a tali servizi e li esamina per vedere come corrispondono alle proprie esigenze. Alcuni servizi su OCI dispongono di livelli elevati di HA incorporati, in particolare servizi gestiti da Oracle, ad esempio il database autonomo. Per garantire che un'architettura di applicazione soddisfi i requisiti aziendali, definire gli SLA di destinazione per ogni carico di lavoro, incluse le dipendenze esterne. Contiene il costo e la complessità di soddisfare i requisiti di disponibilità, oltre alle dipendenze delle applicazioni.
- Stabilire le metriche di recupero— obiettivo tempo di recupero (RTO) e obiettivo punto di recupero (RPO)
RTO è il tempo massimo accettabile che un'applicazione può non essere disponibile dopo un incidente di catastrofe.
RPO è la durata massima della perdita di dati che è accettabile durante un disastro.
Per derivare questi valori, eseguire una valutazione del rischio e assicurarsi di comprendere il costo e il rischio di inattività o perdita di dati nell'organizzazione.
- Definisci un disastro
Avere piani e requisiti ben documentati per il recupero di catastrofi è importante, ma la natura caotica di un tale evento può creare confusione. Comprendere cosa costituisce un disastro per l'azienda, identificare i ruoli chiave che saranno necessari durante un disastro e stabilire un piano di comunicazione ben definito per avviare una risposta al disastro.
Applica best practice architettoniche
Quando si progetta l'architettura, concentrarsi sulle pratiche di implementazione che soddisfano i requisiti aziendali, identificare i punti di guasto e ridurre al minimo l'ambito degli errori.
Prendere in considerazione le seguenti best practice:
- Determina dove potrebbero verificarsi errori
Analizzare l'architettura per identificare i tipi di errori che l'applicazione potrebbe verificarsi, i potenziali effetti di ciascuna e le possibili strategie di recupero.
- Determinare il livello di ridondanza richiesto in base ai requisiti HA e DR
Il livello di ridondanza richiesto per ogni carico di lavoro dipende dalle esigenze e dai fattori aziendali nel costo complessivo dell'applicazione.
- Progettazione per scalabilità
Un'applicazione cloud deve essere in grado di scalare per adeguare le modifiche nell'uso. Iniziare con componenti discreti e progettare l'applicazione per rispondere automaticamente alle modifiche del carico quando possibile. Tenere in considerazione i limiti di ridimensionamento durante la progettazione in modo da poter espandersi facilmente in futuro.
- Utilizzare il bilanciamento del carico per distribuire le richieste
Il bilanciamento del carico distribuisce le richieste dell'applicazione alle istanze di servizio sane rimuovendo le istanze non sane dalla rotazione. L'esternalizzazione delle informazioni sullo stato renderà la scalabilità del backend trasparente per l'utente finale. Se lo stato viene tracciato nella sessione, potrebbe essere necessaria una appiccicosità.
- Crea i requisiti di disponibilità e resilienza nel tuo design
La resilienza è la capacità di un sistema di recuperare da guasti e continuare a funzionare. La disponibilità è la proporzione di tempo in cui il sistema è funzionale e funzionante. Implementare le best practice ad alta disponibilità, ad esempio evitando singoli punti di guasto e decomponendo i carichi di lavoro per obiettivo a livello di servizio. Utilizzare le funzioni standard del layer di dati, ad esempio la continuità dell'applicazione e le transazioni asincrone per garantire disponibilità e resilienza.
- Implementa DR
Progetta la tua soluzione per soddisfare i requisiti RTO e RPO identificati. Assicurarsi di poter portare tutti i componenti della soluzione DR online all'interno della RTO. Proteggi i tuoi dati in modo da poter soddisfare il tuo RPO. Il modo in cui si memorizzano, eseguono il backup e replicano i dati è fondamentale.
- Backup dati
Anche con un ambiente DR completamente replicato, i backup regolari sono ancora critici. Eseguire regolarmente il backup e la convalida dei dati e assicurarsi che nessun singolo account utente abbia accesso sia ai dati di produzione che ai dati di backup.
- Scegliere i metodi di replica per i dati dell'applicazione
I dati dell'applicazione vengono memorizzati in vari data store e potrebbero avere requisiti di disponibilità diversi. Valutare i metodi e le posizioni di replica per ogni tipo di data store per garantire che soddisfino i requisiti HA e RPO.
- Comprendere le implicazioni del fallimento ed è effetto sulla prontezza alle catastrofi
Sarà necessario creare un'istanza di un'altra area per la replica in modo da soddisfare i requisiti dei carichi di lavoro? Dovrai preoccuparti della coerenza dei dati in caso di fallimento?
- Documentare e testare i processi di failover e failback
Chiaramente documentare le istruzioni per fallire in un nuovo data store, e testarli regolarmente per assicurarsi che siano accurate e facili da seguire.
- Assicurarsi che il piano di recupero dati soddisfi l'RTO
Assicurarsi che la strategia di backup e replica preveda tempi di recupero dati che soddisfino l'RTO e l'RPO. Account per tutti i tipi di dati utilizzati dall'applicazione, inclusi dati di riferimento, file e database.
- Backup dati
Prova con Simulazioni e Failover Forzati
Per verificare l'affidabilità è necessario misurare le prestazioni del carico di lavoro end-to-end in condizioni di guasto che si verificano solo in modo intermittente.
- Eseguire il test degli scenari di errore comuni attivando errori effettivi o simulandoli
Utilizzare test di iniezione dei guasti per testare scenari comuni (comprese combinazioni di guasti) e tempi di recupero.
- Identifica gli errori che si verificano solo sotto carico
Test per verificare il massimo carico, utilizzando dati di produzione o dati sintetici il più vicino possibile ai dati di produzione, per vedere come l'applicazione si comporta in condizioni reali.
- Esegui drilling di disaster recovery
Avere un piano di ripristino delle catastrofi in atto, e testarlo periodicamente per assicurarsi che funzioni.
- Esegui test failover e failback
Assicurarsi che i servizi dipendenti dell'applicazione non riescano e non riescano nell'ordine corretto.
- Eseguire test di simulazione
Testare scenari di vita reale può evidenziare problemi che devono essere affrontati. Gli scenari dovrebbero essere controllabili e non dannosi per l'attività. Informare la gestione dei piani di test di simulazione.
- Sonde di stato del test
Configurare le sonde di integrità per load balancer e traffic manager per controllare i componenti di sistema critici. Provali per assicurarsi che rispondano in modo appropriato.
- Sistemi di monitoraggio test
Assicurarsi che i sistemi di monitoraggio comunichino in modo affidabile informazioni critiche e dati accurati per aiutare a identificare potenziali guasti.
- Includi servizi di terze parti negli scenari di test
Test possibili punti di guasto a causa di interruzione del servizio di terze parti, oltre al recupero.
- Imparare dai problemi riscontrati durante i test
Se i test rivelano problemi o lacune, assicurarsi che siano identificati e risolti aggiungendo ulteriori controlli o adeguando i processi operativi.
Distribuisci applicazioni in modo coerente
La distribuzione include il provisioning dei servizi e delle risorse Oracle Cloud Infrastructure (OCI), la distribuzione del codice applicazione e l'applicazione delle impostazioni di configurazione. Un aggiornamento può coinvolgere tutti e tre i compiti o un sottoinsieme di essi.
- Automatizza il processo di distribuzione dell'applicazione
Automatizza il maggior numero possibile di processi. Se possibile, le distribuzioni manuali nella produzione dovrebbero essere eliminate, anche se ciò può essere accettabile in ambienti più bassi per promuovere velocità e flessibilità.
- Sfrutta l'automazione per testare il codice prima della distribuzione
I test per individuare bug, vulnerabilità di sicurezza, funzionalità, prestazioni e integrazioni sono fondamentali per ridurre al minimo i problemi rilevati dagli utenti finali. Gli errori di test dovrebbero impedire che il codice venga rilasciato in produzione.
- Progettare il processo di rilascio per massimizzare la disponibilità
Se il processo di rilascio richiede servizi non in linea durante la distribuzione, l'applicazione non sarà disponibile finché non tornerà in linea. Approfitta delle funzionalità di staging e produzione della piattaforma. Se possibile, rilasciare nuove distribuzioni a un subset di utenti per monitorare gli errori delle prime ore.
- Disporre di un piano di rollback per la distribuzione
Progettare un processo di rollback per tornare a un'ultima versione valida nota e ridurre al minimo i tempi di inattività se una distribuzione non riesce. L'automazione del rollback in caso di distribuzione non riuscita può impedire tempi di inattività inutili.
- Distribuzioni log e audit
Se si utilizzano tecniche di distribuzione posizionate nell'area intermedia, in produzione sono in esecuzione più versioni dell'applicazione. Implementare una solida strategia di registrazione per acquisire il maggior numero possibile di informazioni specifiche per le versioni.
- Documentare il processo di rilascio dell'applicazione
Definisci e documenta chiaramente il processo di rilascio e assicurati che sia disponibile per l'intero team operativo.
Monitor sanità applicazione
Implementare le procedure ottimali per il monitoraggio e gli avvisi nell'applicazione in modo da rilevare gli errori e avvisare un operatore per correggerli.
- Implementa tracciamento intorno alle chiamate di servizio
I dati sulle prestazioni della baseline possono aiutare a fornire i dati di tendenza che possono essere utilizzati per identificare in modo proattivo i problemi relativi alle prestazioni prima che influiscano sugli utenti.
- Implementare sonde sanitarie
Eseguirli regolarmente dall'esterno dell'applicazione per identificare il degrado dello stato e delle prestazioni dell'applicazione. Queste sonde dovrebbero essere più di semplici test statici della pagina, dovrebbero riflettere la salute olistica dell'applicazione.
- Controllare i flussi di lavoro a lungo termine
L'acquisizione dei problemi in anticipo può ridurre al minimo la necessità di eseguire il rollback dell'intero flusso di lavoro o di eseguire più transazioni di compensazione.
- Gestire i log di sistema, applicazione e audit
Utilizzare un servizio di log centralizzato per memorizzare i log.
- Impostare un sistema di allarme rapido
Identificare gli indicatori KPI (Key Performance Indicators) dello stato di un'applicazione, ad esempio eccezioni transitorie e latenza di chiamata remota, e impostare i valori di soglia appropriati per ciascuno di essi. Invia un avviso alle operazioni quando viene raggiunto il valore soglia.
- Formare più operatori per monitorare l'applicazione e per eseguire passi di recupero manuale
Assicurarsi che sia sempre attivo almeno un operatore addestrato.
Gestisci errori e disinstallazioni
Creare un piano di recupero e assicurarsi che copra il ripristino dei dati, le interruzioni di rete, gli errori dei servizi dipendenti e le interruzioni dei servizi a livello di area. Considerare le VM, lo storage, i database e altri servizi OCI nella strategia di recupero.
- Piano per le interazioni di supporto OCI
Prima della necessità, stabilire un processo per contattare il supporto OCI.
- Documentare e testare il piano di disaster recovery
Scrivere un piano di disaster recovery che rifletta l'impatto aziendale degli errori dell'applicazione. Automatizza il processo di recupero il più possibile e documenta eventuali passaggi manuali. Eseguire regolarmente il test del processo di disaster recovery per convalidare e migliorare il piano.
- Comprendere i ruoli chiave necessari per il coordinamento DR
Assicurarsi che gli sforzi DR siano ben coordinati e che le applicazioni siano prioritarie in base al valore aziendale.
- Preparazione per errore applicazione
Prepararsi per un intervallo di errori, inclusi gli errori gestiti automaticamente, quelli che provocano funzionalità ridotte e quelli che causano l'indisponibilità dell'applicazione. L'applicazione dovrebbe informare gli utenti di problemi temporanei.
- Recuperare dalla corruzione dei dati
Se si verifica un errore in un data store, verificare le incoerenze dei dati quando l'area di memorizzazione diventa nuovamente disponibile, in particolare se i dati sono stati replicati. Ripristina i dati danneggiati da un backup.
- Recupera da un'interruzione della rete
È possibile utilizzare i dati inseriti nella cache per eseguire localmente con funzionalità di applicazione ridotte. In caso contrario, prendere in considerazione i tempi di inattività dell'applicazione o eseguire il failover in un'altra area. Memorizzare i dati in una posizione alternativa fino al ripristino della connettività.
- Recupero da un errore di servizio dipendente
Determinare la funzionalità ancora disponibile e le modalità di risposta dell'applicazione.
- Recuperare da un'interruzione del servizio a livello regionale
Le interruzioni del servizio a livello regionale non sono comuni, ma si dovrebbe avere una strategia per affrontarle, soprattutto per le applicazioni critiche. È possibile ridistribuire l'applicazione in un'altra area o ridistribuire il traffico.
- Imparare dai test DR e migliorare i processi
Assicurarsi che tutti i problemi rilevati durante il test DR vengano acquisiti e che i piani per risolvere tali problemi vengano risolti in test o errori futuri.