La figura seguente mostra la vista logica della comunicazione tra il server SnapCenter , il database SAP HANA e il sistema di archiviazione. Il server SnapCenter sfrutta i plug-in HANA e Linux per comunicare con il database HANA e i sistemi operativi Linux.

L'opzione di distribuzione consigliata e predefinita per i plug-in SnapCenter è l'installazione sull'host del database HANA. Con questa opzione di distribuzione, tutte le configurazioni e le funzionalità descritte nel capitolo Configurazione supportata SnapCenter sono valide. Esistono alcune eccezioni in cui i plug-in SnapCenter non possono essere installati sull'host del database HANA, ma devono essere configurati su un host di plug-in centrale, che potrebbe essere il server SnapCenter stesso. Per i sistemi HANA con più host o per i sistemi HANA in esecuzione sulla piattaforma IBM Power è necessario un host plug-in centrale. Entrambe le opzioni di distribuzione possono anche essere combinate, ad esempio utilizzando il server SnapCenter come host di plug-in centrale per un sistema host multiplo e distribuendo i plug-in sugli host del database HANA per tutti gli altri sistemi HANA con host singolo.

In SnapCenter una risorsa HANA può essere rilevata automaticamente o configurata manualmente. Per impostazione predefinita, un sistema HANA viene rilevato automaticamente non appena i plug-in HANA e Linux vengono distribuiti sull'host del database. La rilevazione automatica SnapCenter non supporta più installazioni HANA sullo stesso host. I sistemi HANA gestiti tramite un host plug-in centrale devono essere configurati manualmente in SnapCenter. Inoltre, i volumi non dati sono per impostazione predefinita risorse configurate manualmente.

Sebbene SnapCenter supporti la distribuzione centralizzata di plug-in per i sistemi HANA, vi sono limitazioni nel supporto di piattaforme e funzionalità. Le seguenti configurazioni e operazioni infrastrutturali non sono supportate per i sistemi HANA configurati con un host plug-in centrale:

SAP consiglia di includere controlli regolari della coerenza dei blocchi HANA nella strategia di backup complessiva. Con i backup tradizionali basati su file, questo controllo viene eseguito a ogni operazione di backup. Con i backup Snapshot, il controllo di coerenza deve essere eseguito oltre alle operazioni di backup Snapshot, ad esempio una volta alla settimana.

Tecnicamente ci sono due opzioni per eseguire il controllo di coerenza dei blocchi.

Lo strumento HANA hdbpersdiag fa parte dell'installazione di HANA e consente di eseguire operazioni di controllo della coerenza dei blocchi su un database HANA offline. Pertanto è perfetto per essere utilizzato in combinazione con i backup Snapshot, dove i backup Snapshot esistenti possono essere presentati a hdbpersdiag.

Confrontando i due approcci, hdbpersdiag presenta notevoli vantaggi rispetto al backup basato su file per i controlli di coerenza dei blocchi HANA. Una dimensione è la capacità di archiviazione richiesta. Con i backup basati su file, per ogni sistema HANA deve essere disponibile almeno la dimensione di un backup. Ad esempio, se si dispone di 15 sistemi HANA con una dimensione di persistenza di 3 TB, sarebbero necessari altri 45 TB solo per i controlli di coerenza. Con hdbpersdiag non è richiesta alcuna capacità di archiviazione aggiuntiva poiché l'operazione viene eseguita su un backup Snapshot esistente o su un FlexClone di un backup Snapshot esistente. La seconda dimensione è il carico della CPU sull'host HANA durante l'operazione di controllo della coerenza. Un backup basato su file richiederà cicli di CPU sull'host del database HANA, mentre l'elaborazione hdbpersdiag può essere completamente scaricata dall'host HANA se utilizzata in combinazione con un host di verifica centrale. La tabella seguente riassume le caratteristiche principali.

NetApp consiglia di utilizzare hdbpersdiag per eseguire i controlli di coerenza dei blocchi HANA. Ulteriori dettagli sull'implementazione sono disponibili nel capitolo "Controlli di coerenza dei blocchi con SnapCenter".

Prima di configurare SnapCenter e il plug-in SAP HANA, la strategia di protezione dei dati deve essere definita in base ai requisiti RTO e RPO dei vari sistemi SAP.

Un approccio comune consiste nella definizione di tipi di sistema quali produzione, sviluppo, test o sistemi sandbox. Tutti i sistemi SAP dello stesso tipo di sistema hanno in genere gli stessi parametri di protezione dei dati.

I parametri da definire sono:

La tabella seguente mostra un esempio di parametri di protezione dei dati per i tipi di sistema produzione, sviluppo e test. Per il sistema di produzione è stata definita un'elevata frequenza di backup e i backup vengono replicati su un sito di backup secondario una volta al giorno. I sistemi di test hanno requisiti inferiori e non richiedono la replica dei backup.

Nella tabella seguente sono riportati i criteri e le pianificazioni che devono essere configurati per i parametri di protezione dei dati sopra indicati.

La figura seguente riassume le pianificazioni e le conservazioni dei backup. Se si utilizza SnapCenter per gestire la conservazione dei backup dei log, tutti i backup dei log più vecchi del backup Snapshot più vecchio verranno eliminati. In altre parole, i backup del registro vengono conservati per tutto il tempo necessario a consentire il ripristino in tempo utile per ogni backup disponibile.

Quando si utilizza la crittografia persistente HANA, è fondamentale creare backup delle chiavi radice oltre ai backup dei dati standard. I backup della chiave radice sono necessari per ripristinare il database HANA nel caso in cui il volume di dati e il file system di installazione HANA vengano persi. Per maggiori informazioni vedere "Guida all'amministrazione di SAP HANA".

SnapCenter supporta le operazioni di backup Snapshot dei sistemi HANA MDC con uno o più tenant. SnapCenter supporta anche due diverse operazioni di ripristino di un sistema HANA MDC. È possibile ripristinare l'intero sistema, il database di sistema e tutti i tenant, oppure ripristinare solo un tenant. Per consentire a SnapCenter di eseguire queste operazioni, sono necessari alcuni prerequisiti.

In un sistema MDC, la configurazione del tenant non è necessariamente statica. È possibile aggiungere o eliminare inquilini. SnapCenter non può basarsi sulla configurazione rilevata quando il database HANA viene aggiunto a SnapCenter. Per abilitare un'operazione di ripristino di un singolo tenant, SnapCenter deve sapere quali tenant sono inclusi in ciascun backup Snapshot. Inoltre, deve sapere quali file e directory appartengono a ciascun tenant incluso nel backup Snapshot.

Pertanto, a ogni operazione di backup, SnapCenter identifica le informazioni sul tenant. Ciò include i nomi dei tenant e le informazioni corrispondenti sui file e sulle directory. Questi dati devono essere archiviati nei metadati del backup Snapshot per poter supportare un'operazione di ripristino di un singolo tenant.

Un altro passaggio del rilevamento automatico dell'applicazione è il rilevamento del nodo primario o secondario di HANA System Replication (HSR). Se un sistema HANA è configurato con HSR, SnapCenter deve identificare il nodo primario con ogni operazione di backup in modo che i comandi SQL di backup vengano eseguiti sul nodo primario HSR. Vedi anche "Replica di sistema SAP HANA - backup e recovery con SnapCenter".

SnapCenter rileva anche la configurazione del volume dati HANA e la mappa al file system e alle risorse di archiviazione. Con questo approccio, SnapCenter può gestire le modifiche alla configurazione del volume HANA, ad esempio più partizioni o modifiche alla configurazione dell'archiviazione come le migrazioni dei volumi.

Il passaggio successivo è l'operazione di backup Snapshot vera e propria. Questo passaggio include il comando SQL per attivare lo snapshot del database HANA, il backup dello snapshot di archiviazione e il comando SQL per chiudere l'operazione di snapshot HANA. Utilizzando il comando close, il database HANA aggiorna il catalogo di backup del DB di sistema e di ciascun tenant.

Per la gestione della conservazione dei backup dei dati e della gestione del catalogo di backup HANA, SnapCenter deve eseguire le operazioni di eliminazione del catalogo per il database di sistema e per tutti i database tenant identificati nella prima fase. Allo stesso modo per i backup dei log, il flusso di lavoro di SnapCenter deve operare su ogni tenant che faceva parte dell'operazione di backup.

La figura seguente mostra una panoramica del flusso di lavoro di backup.

La gestione della conservazione dei backup dei dati e la gestione del backup dei log possono essere suddivise in cinque aree principali, tra cui la gestione della conservazione di:

La figura seguente fornisce una panoramica dei diversi flussi di lavoro e delle dipendenze di ciascuna operazione. Le sezioni seguenti descrivono in dettaglio le diverse operazioni.