Progettare per il ripristino
 Il carico di lavoro deve essere in grado di prevedere la maggior parte degli errori, di qualsiasi entità, e di ripristinarsi con un'interruzione minima dell'esperienza utente e degli obiettivi di business. |
|---|
Anche i sistemi altamente resilienti hanno bisogno di un approccio che li prepari alle emergenze, sia nella progettazione dell'architettura che nelle operazioni del carico di lavoro. Nel livello dati è necessario avere strategie che possono ripristinare lo stato del carico di lavoro in caso di danneggiamento.
Scenario di esempio
Contoso ospita attualmente una grande quantità di dati in un database di SQL Server locale e ha di recente modernizzato la soluzione di analisi per i dati con i servizi di Azure.
La nuova soluzione di analisi usa Azure Analysis Services, Azure Data Factory, Azure Synapse Analytics, Power BI e Macchine virtuali di Azure. Tutti gli utenti della soluzione sono interni. Dopo aver considerato i requisiti di disponibilità della soluzione, il team decide di implementare la soluzione in un'unica area geografica.
I dati vengono inseriti usando Azure Data Factory ed elaborati prima di essere salvati nell'archiviazione di Analysis Services. Parte della procedura richiede un processo Windows legacy, distribuito in una macchina virtuale nel cloud.
Prepararsi per le emergenze
Avere piani di ripristino strutturati, testati e documentati che sono allineati agli obiettivi di ripristino negoziati. I piani devono coprire tutti i componenti, oltre al sistema nel suo complesso.
Un processo ben definito comporta un rapido ripristino che consente di evitare un impatto negativo sulle finanze e sulla reputazione dell'azienda. Condurre esercitazioni di ripristino regolari consente di verificare il processo di ripristino dei componenti di sistema, dei dati e dei passaggi di failover e failback per evitare confusione quando il tempo e l'integrità dei dati sono le chiavi del successo.
Sfida di Contoso
- La soluzione viene usata solo internamente e non è considerata mission-critical. Pertanto, il team addetto al carico di lavoro e gli stakeholder aziendali concordano sul fatto che la ricostruzione della soluzione in un'area secondaria sia un modello di recupero sufficiente nell'improbabile caso che l'area di Azure in cui è distribuita venga persa o che l'intera soluzione non sia disponibile per altri motivi.
- Il team che si occupa del carico di lavoro descrive come creare la soluzione in un'altra area del piano di ripristino di emergenza, ma non ha ancora avuto la possibilità di eseguire un'esercitazione completa sul ripristino di emergenza.
Applicazione dell'approccio e risultati
- Dopo aver riscontrato un'interruzione a livello di area, il team responsabile della risposta al ripristino di emergenza è in grado di seguire le istruzioni del piano di ripristino di emergenza per ridistribuire la soluzione di analisi in un'altra area.
- Il team individua lacune nei piani di ripristino di emergenza per alcune delle operazioni necessarie per distribuire la soluzione e il piano viene aggiornato per rendere il ripristino più efficiente in futuro.
- Il team responsabile del carico di lavoro e gli stakeholder concordano di accelerare i test sul ripristino di emergenza pianificati per garantire che il piano aggiornato consenta un ripristino più efficiente.
Gestire i dati con stato
Assicurarsi di poter ripristinare i dati di tutti i componenti con stato all'interno delle destinazioni di ripristino.
I backup sono essenziali per ripristinare lo stato di funzionamento del sistema usando un punto di recupero attendibile, ad esempio l'ultimo stato valido noto.
I backup non modificabili e coerenti in modo transazionale garantiscono che i dati non possano essere alterati e che i dati ripristinati non siano danneggiati.
Sfida di Contoso
- Il team responsabile del carico di lavoro decide di trasferire i database SQL in Azure per ridurre i tempi di elaborazione dell'analisi. Uno dei database viene ampiamente usato durante il processo di analisi delle macchine virtuali, pertanto il team deve assicurarsi che lo stato del database possa essere recuperato con l'RPO più basso possibile.
Applicazione dell'approccio e risultati
- Poiché i database hanno dimensioni superiori a 4 TB, la migrazione sul database SQL di Azure non è realizzabile a breve termine. Il team esegue quindi la migrazione verso le macchine virtuali di Azure che eseguono SQL Server 2022.
- Il team decide di usare la funzione di backup automatico per tutti i database, inclusi quelli critici, come quello usato dalle macchine virtuali.
- Per i database critici, il team prevede di usare la funzione di backup automatico insieme alla funzione di collegamento dell'istanza gestita per replicare attivamente i database in un'istanza gestita di SQL di Azure.
Implementare nella progettazione funzionalità di self-healing automatico
Le funzionalità di self-healing automatico sono meccanismi che consentono ai componenti del carico di lavoro di risolvere automaticamente i problemi ripristinando i componenti interessati e, se necessario, eseguendo il failover dell'infrastruttura ridondante. Usare i modelli di progettazione per aggiungere resilienza al carico di lavoro tramite meccanismi di self-healing.
Il self-healing automatico consente di ridurre i rischi derivanti da fattori esterni come l'intervento umano e riduce il ciclo di correzione delle interruzioni.
Sfida di Contoso
- Il processo di Windows richiamato da Azure Data Factory durante l'inserimento dei dati è stato inizialmente distribuito in più macchine virtuali per una maggiore disponibilità.
- Esistono alcuni casi in cui il processo Windows legacy si è arrestato in modo anomalo, richiedendo un riavvio della macchina virtuale. Anche se il tempo di elaborazione complessivo è stato solo minimamente interessato (per via del livello di ridondanza), il team vuole implementare una soluzione che automatizzi il rilevamento dell'errore e il ripristino.
Applicazione dell'approccio e risultati
- Il team decide di implementare una soluzione del set di scalabilità di macchine virtuali di Azure, configurata per distribuire l'estensione integrità dell'applicazione per monitorare in modo costante l'integrità del processo della macchina virtuale.
- Con il ripristino automatico dell'istanza abilitato, il set di scalabilità è ora in grado di ripristinare il componente riavviando la macchina virtuale o creando una nuova istanza basata sulla stessa immagine.