Best Practice
Casi d'utilizzo per il refresh e la clonazione del sistema
Suggerisci modifiche
PDF
Esistono diversi scenari in cui i dati di un sistema di origine devono essere resi disponibili a un sistema di destinazione per scopi di test o formazione. Questi sistemi di test e formazione devono essere aggiornati regolarmente con i dati del sistema di origine per assicurarsi che i test e la formazione vengano eseguiti con il set di dati corrente.
Queste operazioni di refresh del sistema sono costituite da più attività a livello di infrastruttura, database e applicazioni e possono richiedere più giorni a seconda del livello di automazione.
La seguente figura illustra le operazioni di aggiornamento, copia e clonazione del sistema SAP.
I flussi di lavoro per la clonazione SnapCenter possono essere utilizzati per accelerare e automatizzare le attività richieste a livello di infrastruttura e database. Invece di ripristinare un backup dal sistema di origine al sistema di destinazione, SnapCenter utilizza la copia Snapshot di NetApp e la tecnologia FlexClone, in modo che le attività necessarie fino a un database HANA avviato possano essere eseguite in pochi minuti invece che in ore, come mostrato nella figura seguente. Il tempo necessario per il processo di cloning è indipendente dalle dimensioni del database, pertanto è possibile creare anche sistemi molto grandi in un paio di minuti.
La figura seguente mostra l'aggiornamento dei dati di sistemi di QA, test, sandbox o training.
Il flusso di lavoro per le operazioni di refresh del sistema è descritto nella sezione ""Aggiornamento del sistema SAP HANA con SnapCenter"."
Risolvere il danneggiamento logico
La corruzione logica può essere causata da errori software, errori umani o sabotaggio. Purtroppo, spesso la corruzione logica non può essere affrontata con soluzioni standard di alta disponibilità e disaster recovery. Di conseguenza, a seconda del livello, dell'applicazione, del file system o dello storage in cui si è verificato il danneggiamento logico, i requisiti minimi di downtime e di perdita massima dei dati possono talvolta non essere soddisfatti.
Il caso peggiore è la corruzione logica in un'applicazione SAP. Le applicazioni SAP spesso operano in un ambiente in cui diverse applicazioni comunicano tra loro e scambiano dati. Pertanto, il ripristino e il ripristino di un sistema SAP in cui si è verificato un danneggiamento logico non è l'approccio consigliato. Il ripristino del sistema a un punto temporale prima che si verificasse il danneggiamento comporta la perdita di dati. Inoltre, il panorama SAP non sarebbe più sincronizzato e richiederebbe un'ulteriore post-elaborazione.
Invece di ripristinare il sistema SAP, l'approccio migliore consiste nel cercare di correggere l'errore logico all'interno del sistema analizzando il problema in un sistema di riparazione separato. L'analisi della causa principale richiede il coinvolgimento del processo di business e del proprietario dell'applicazione. Per questo scenario, si crea un sistema di riparazione (un clone del sistema di produzione) basato sui dati memorizzati prima che si verificasse il danneggiamento logico. All'interno del sistema di riparazione, i dati richiesti possono essere esportati e importati nel sistema di produzione. Con questo approccio, non è necessario arrestare il sistema di produzione e, nel migliore dei casi, non vengono persi dati o solo una piccola parte di dati.
Quando si configura il sistema di riparazione, la flessibilità e la velocità sono fondamentali. Con i backup Snapshot basati su storage NetApp, sono disponibili più immagini di database coerenti per creare un clone del sistema di produzione utilizzando la tecnologia NetApp FlexClone, come mostrato nella figura seguente. I volumi FlexClone possono essere creati in pochi secondi anziché in più ore se per configurare il sistema di riparazione viene utilizzato un ripristino reindirizzato da un backup basato su file.
Il flusso di lavoro per la creazione del sistema di riparazione è descritto nella sezione ""Clone del sistema SAP con SnapCenter"."
Test di disaster recovery
Una strategia di disaster recovery efficace richiede la verifica del flusso di lavoro richiesto. I test dimostrano se la strategia funziona e se la documentazione interna è sufficiente. Consente inoltre agli amministratori di seguire le procedure richieste.
La replica dello storage con SnapMirror consente di eseguire test di disaster recovery senza mettere a rischio RTO e RPO. I test di disaster recovery possono essere eseguiti senza interrompere la replica dei dati.
I test di disaster recovery per SnapMirror asincrono e sincrono utilizzano i backup Snapshot e i volumi FlexClone alla destinazione del disaster recovery.
La seguente figura illustra i test di disaster recovery.
Una descrizione dettagliata e dettagliata è disponibile nel report tecnico "Disaster recovery SAP HANA con replica dello storage".