Best Practice
TR-4614: Backup e recovery SAP HANA con SnapCenter
Suggerisci modifiche
PDF
Nils Bauer, NetApp
Le aziende oggi richiedono una disponibilità continua e ininterrotta per le proprie applicazioni SAP. Si aspettano livelli di performance costanti di fronte a volumi di dati in continua crescita e alla necessità di attività di manutenzione ordinaria come i backup di sistema. L'esecuzione di backup dei database SAP è un'attività critica e può avere un impatto significativo sulle performance del sistema SAP di produzione.
Le finestre di backup si stanno riducendo, mentre la quantità di dati da sottoporre a backup aumenta. Pertanto, è difficile trovare un momento in cui i backup possono essere eseguiti con un effetto minimo sui processi di business. Il tempo necessario per ripristinare e ripristinare i sistemi SAP è un problema, perché i downtime per i sistemi di produzione SAP e non in produzione devono essere ridotti al minimo per ridurre la perdita di dati e i costi per l'azienda.
I seguenti punti riassumono le sfide che devono affrontare il backup e il recovery SAP:
-
Effetti delle performance sui sistemi SAP di produzione. in genere, i backup tradizionali basati su copia creano un significativo scolo delle performance sui sistemi SAP di produzione a causa dei carichi pesanti posti sul server di database, sul sistema storage e sulla rete storage.
-
Riduzione delle finestre di backup. i backup convenzionali possono essere eseguiti solo quando sono in corso poche attività di dialogo o batch sul sistema SAP. La pianificazione dei backup diventa più difficile quando i sistemi SAP vengono utilizzati 24 ore su 24.
-
Rapida crescita dei dati. la rapida crescita dei dati e la riduzione delle finestre di backup richiedono investimenti continui nell'infrastruttura di backup. In altre parole, è necessario procurarsi più unità nastro, ulteriore spazio su disco per il backup e reti di backup più veloci. È inoltre necessario coprire le spese di storage e gestione di tali risorse su nastro. I backup incrementali o differenziali possono risolvere questi problemi, ma questa disposizione comporta un processo di ripristino molto lento, complicato e complesso, più difficile da verificare. Tali sistemi di solito aumentano i tempi di obiettivi del tempo di ripristino (RTO) e di obiettivi del punto di ripristino (RPO) in modi che non sono accettabili per l'azienda.
-
Aumento del costo del downtime. il downtime non pianificato di un sistema SAP influisce in genere sulle finanze aziendali. Una parte significativa di qualsiasi downtime non pianificato viene consumata dal requisito di ripristino e ripristino del sistema SAP. Pertanto, l'RTO desiderato determina la progettazione dell'architettura di backup e ripristino.
-
Tempi di backup e recovery per i progetti di upgrade SAP. il piano di progetto per un upgrade SAP include almeno tre backup del database SAP. Questi backup riducono significativamente il tempo disponibile per il processo di aggiornamento. La decisione di procedere si basa generalmente sul tempo necessario per ripristinare e ripristinare il database dal backup creato in precedenza. Invece di ripristinare semplicemente un sistema allo stato precedente, un ripristino rapido offre più tempo per risolvere i problemi che potrebbero verificarsi durante un aggiornamento.
La soluzione NetApp
La tecnologia NetApp Snapshot può essere utilizzata per creare backup di database in pochi minuti. Il tempo necessario per creare una copia Snapshot è indipendente dalle dimensioni del database, in quanto una copia Snapshot non sposta alcun blocco di dati fisico sulla piattaforma di storage. Inoltre, l'utilizzo della tecnologia Snapshot non ha alcun effetto sulle performance del sistema SAP live, in quanto la tecnologia Snapshot di NetApp non sposta o copia i blocchi di dati quando viene creata la copia Snapshot o quando vengono modificati i dati nel file system attivo. Pertanto, la creazione di copie Snapshot può essere pianificata senza considerare i periodi di dialogo di picco o di attività batch. I clienti SAP e NetApp pianificano in genere più backup Snapshot online durante il giorno; ad esempio, ogni quattro ore è comune. Questi backup Snapshot vengono in genere conservati per tre o cinque giorni nel sistema di storage primario prima di essere rimossi.
Le copie Snapshot offrono anche vantaggi chiave per le operazioni di ripristino e ripristino. Il software di ripristino dei dati NetApp SnapRestore consente di ripristinare un intero database o, in alternativa, una parte di un database in qualsiasi momento, in base alle copie Snapshot disponibili. Tali processi di ripristino vengono completati in pochi minuti, indipendentemente dalle dimensioni del database. Poiché durante la giornata vengono creati diversi backup Snapshot online, il tempo necessario per il processo di ripristino viene ridotto in modo significativo rispetto a un approccio di backup tradizionale. Poiché un ripristino può essere eseguito con una copia Snapshot che ha poche ore di vita (anziché fino a 24 ore), è necessario applicare un numero inferiore di registri delle transazioni. Pertanto, l'RTO viene ridotto a diversi minuti piuttosto che alle diverse ore richieste per i backup su nastro convenzionali a ciclo singolo.
I backup delle copie Snapshot vengono memorizzati sullo stesso sistema di dischi dei dati online attivi. Pertanto, NetApp consiglia di utilizzare i backup di copia Snapshot come supplemento piuttosto che come sostituto per i backup in una posizione secondaria. La maggior parte delle azioni di ripristino e ripristino viene gestita utilizzando SnapRestore sul sistema di storage primario. I ripristini da una posizione secondaria sono necessari solo se il sistema di storage primario contenente le copie Snapshot viene danneggiato. La posizione secondaria può essere utilizzata anche se è necessario ripristinare un backup non più disponibile da una copia Snapshot, ad esempio un backup di fine mese.
Un backup in una posizione secondaria si basa sulle copie Snapshot create sullo storage primario. Pertanto, i dati vengono letti direttamente dal sistema di storage primario senza generare carico sul server di database SAP. Lo storage primario comunica direttamente con lo storage secondario e invia i dati di backup alla destinazione utilizzando un backup disk-to-disk di NetApp SnapVault.
SnapVault offre vantaggi significativi rispetto ai backup tradizionali. Dopo un trasferimento iniziale dei dati, in cui tutti i dati sono stati trasferiti dall'origine alla destinazione, tutti i backup successivi copiano solo i blocchi modificati nello storage secondario. Pertanto, il carico sul sistema di storage primario e il tempo necessario per un backup completo sono notevolmente ridotti. Poiché SnapVault memorizza solo i blocchi modificati nella destinazione, un backup completo del database richiede meno spazio su disco.
La soluzione può anche essere facilmente estesa a un modello operativo di cloud ibrido. La replica dei dati per il disaster recovery o il backup fuori sede può essere eseguita dai sistemi NetApp ONTAP on-premise alle istanze di Cloud Volumes ONTAP in esecuzione nel cloud. È possibile utilizzare SnapCenter come strumento centrale per gestire la protezione dei dati e la replica dei dati, indipendentemente dal fatto che il sistema SAP HANA venga eseguito on-premise o nel cloud. La figura seguente mostra una panoramica della soluzione di backup.
Esecuzione dei backup Snapshot
La schermata successiva mostra HANA Studio di un cliente che esegue SAP HANA su storage NetApp. Il cliente utilizza le copie Snapshot per eseguire il backup del database HANA. L'immagine mostra che il backup del database HANA (di circa 2,3 TB) viene eseguito in 2 minuti e 11 secondi utilizzando la tecnologia di backup Snapshot.
|
La parte più importante del runtime complessivo del workflow di backup è il tempo necessario per eseguire l'operazione di salvataggio del backup HANA, che dipende dal carico sul database HANA. Il backup Snapshot dello storage viene sempre completato in un paio di secondi. |
Confronto degli obiettivi del tempo di ripristino
Questa sezione fornisce un confronto RTO tra i backup Snapshot basati su file e su storage. L'RTO è definito dalla somma del tempo necessario per ripristinare il database e del tempo necessario per avviare e ripristinare il database.
Tempo necessario per il ripristino del database
Con un backup basato su file, il tempo di ripristino dipende dalle dimensioni del database e dell'infrastruttura di backup, che definisce la velocità di ripristino in megabyte al secondo. Ad esempio, se l'infrastruttura supporta un'operazione di ripristino a una velocità di 250 MBps, il ripristino di un database di 1 TB richiede circa 1 ora e 10 minuti.
Con i backup delle copie Snapshot dello storage, il tempo di ripristino è indipendente dalle dimensioni del database e si trova nell'intervallo di un paio di secondi in cui il ripristino può essere eseguito dallo storage primario. Il ripristino dallo storage secondario è necessario solo in caso di disastro quando lo storage primario non è più disponibile.
Tempo necessario per avviare il database
L'ora di inizio del database dipende dalle dimensioni dell'archivio di righe e colonne. Per l'archivio di colonne, l'ora di inizio dipende anche dalla quantità di dati precaricati durante l'avvio del database. Negli esempi seguenti, si presuppone che l'ora di inizio sia di 30 minuti. L'ora di inizio è la stessa per un ripristino e un ripristino basati su file e per un ripristino e un ripristino basati su Snapshot.
Tempo necessario per il ripristino del database
Il tempo di ripristino dipende dal numero di registri che devono essere applicati dopo il ripristino. Questo numero è determinato dalla frequenza con cui vengono eseguiti i backup dei dati.
Con i backup dei dati basati su file, la pianificazione del backup è generalmente una volta al giorno. In genere, non è possibile una frequenza di backup più elevata, poiché il backup diminuisce le prestazioni di produzione. Pertanto, nel peggiore dei casi, tutti i log scritti durante la giornata devono essere applicati durante il recupero in avanti.
I backup dei dati di copia Snapshot dello storage vengono in genere pianificati con una frequenza maggiore perché non influiscono sulle prestazioni del database SAP HANA. Ad esempio, se i backup delle copie Snapshot vengono pianificati ogni sei ore, il tempo di ripristino sarebbe, nel peggiore dei casi, un quarto del tempo di ripristino per un backup basato su file (6 ore / 24 ore = ¼).
La figura seguente mostra un esempio RTO per un database da 1 TB quando vengono utilizzati backup dei dati basati su file. In questo esempio, un backup viene eseguito una volta al giorno. L'RTO varia in base al momento in cui sono stati eseguiti il ripristino e il ripristino. Se il ripristino e il ripristino sono stati eseguiti immediatamente dopo l'esecuzione di un backup, l'RTO si basa principalmente sul tempo di ripristino, che nell'esempio è di 1 ora e 10 minuti. Il tempo di ripristino è aumentato a 2 ore e 50 minuti quando il ripristino e il ripristino sono stati eseguiti immediatamente prima del backup successivo e l'RTO massimo è stato di 4 ore e 30 minuti.
La figura seguente mostra un esempio RTO per un database da 1 TB quando vengono utilizzati backup Snapshot. Con i backup Snapshot basati sullo storage, l'RTO dipende solo dall'ora di avvio del database e dal tempo di ripristino in avanti, in quanto il ripristino viene completato in pochi secondi, indipendentemente dalle dimensioni del database. Il tempo di recupero in avanti aumenta anche a seconda del momento in cui vengono eseguiti il ripristino e il ripristino, ma a causa della maggiore frequenza dei backup (ogni sei ore in questo esempio), il tempo di recupero in avanti è di 43 minuti al massimo. In questo esempio, l'RTO massimo è di 1 ora e 13 minuti.
La figura seguente mostra un confronto RTO tra backup Snapshot basati su file e storage per database di dimensioni diverse e frequenze diverse dei backup Snapshot. La barra verde mostra il backup basato su file. Le altre barre mostrano i backup delle copie Snapshot con frequenze di backup diverse.
Con un singolo backup dei dati di copia Snapshot al giorno, l'RTO è già ridotto del 40% rispetto a un backup dei dati basato su file. La riduzione aumenta fino al 70% quando vengono eseguiti quattro backup Snapshot al giorno. La figura mostra inoltre che la curva si appiattire se si aumenta la frequenza di backup Snapshot a più di quattro o sei backup Snapshot al giorno. I nostri clienti configurano quindi da quattro a sei backup Snapshot al giorno.
|
|
Il grafico mostra le dimensioni della RAM del server HANA. La dimensione del database in memoria è calcolata in modo da essere la metà della dimensione della RAM del server. |
|
|
I tempi di ripristino e ripristino vengono calcolati in base ai seguenti presupposti. Il database può essere ripristinato a 250 MBps. Il numero di file di log al giorno corrisponde al 50% delle dimensioni del database. Ad esempio, un database da 1 TB crea 500 MB di file di log al giorno. È possibile eseguire un ripristino a 100 Mbps. |