Architettura
Suggerisci modifiche
PDF
Gli host SAP HANA sono connessi ai controller di storage utilizzando un'infrastruttura di rete ridondante da 10 GbE o più veloce. La comunicazione dei dati tra gli host SAP HANA e i controller di storage si basa sul protocollo NFS.
Si consiglia di utilizzare un'infrastruttura di switching ridondante per fornire una connettività host-to-storage SAP HANA fault-tolerant in caso di guasto dello switch o della scheda di interfaccia di rete (NIC). Gli switch potrebbero aggregare le performance delle singole porte con i canali delle porte in modo da apparire come una singola entità logica a livello di host.
Diversi modelli della famiglia di sistemi FAS possono essere combinati e abbinati a livello di storage per consentire la crescita e le diverse esigenze di performance e capacità. Il numero massimo di host SAP HANA che possono essere collegati al sistema storage è definito dai requisiti di performance SAP HANA e dal modello di controller NetApp utilizzato. Il numero di shelf di dischi richiesti è determinato solo dai requisiti di capacità e performance dei sistemi SAP HANA. La figura seguente mostra una configurazione di esempio con otto host SAP HANA collegati a una coppia di storage ad alta disponibilità (ha).
La figura seguente mostra un esempio di utilizzo di VMware vSphere come livello di virtualizzazione.
L'architettura può essere scalata in due dimensioni:
-
Collegando altri host SAP HANA e/o capacità di storage allo storage esistente, se i controller di storage forniscono performance sufficienti per soddisfare gli attuali indicatori chiave di performance SAP (KPI)
-
Aggiungendo altri sistemi storage con capacità di storage aggiuntiva per gli host SAP HANA aggiuntivi
La figura seguente mostra una configurazione di esempio in cui più host SAP HANA sono collegati ai controller di storage. In questo esempio, sono necessari più shelf di dischi per soddisfare i requisiti di capacità e performance di 16 host SAP HANA. A seconda dei requisiti di throughput totale, è necessario aggiungere ulteriori connessioni 10 GbE (o più veloci) ai controller di storage.
Indipendentemente dal sistema FAS implementato, il panorama SAP HANA può essere scalato aggiungendo uno qualsiasi dei controller di storage certificati per soddisfare la densità di nodo desiderata (figura seguente).
Backup SAP HANA
Il software ONTAP presente su tutti i controller di storage NetApp offre un meccanismo integrato per eseguire il backup dei database SAP HANA durante il funzionamento senza alcun effetto sulle performance. I backup NetApp Snapshot basati su storage sono una soluzione di backup completamente supportata e integrata disponibile per i singoli container SAP HANA e per i sistemi SAP HANA Multitenant Database Container (MDC) con un singolo tenant o più tenant.
I backup Snapshot basati su storage vengono implementati utilizzando il plug-in NetApp SnapCenter per SAP HANA. Ciò consente agli utenti di creare backup Snapshot coerenti basati sullo storage utilizzando le interfacce fornite in modo nativo dai database SAP HANA. SnapCenter registra tutti i backup Snapshot nel catalogo di backup SAP HANA. Pertanto, i backup eseguiti da SnapCenter sono visibili all'interno di SAP HANA Studio e Cockpit, dove possono essere selezionati direttamente per le operazioni di ripristino e recovery.
La tecnologia NetApp SnapMirror consente di replicare le copie Snapshot create su un sistema storage su un sistema storage di backup secondario controllato da SnapCenter. È quindi possibile definire diversi criteri di conservazione dei backup per ciascuno dei set di backup sullo storage primario e per i set di backup sui sistemi di storage secondari. Il plug-in SnapCenter per SAP HANA gestisce automaticamente la conservazione dei backup dei dati basati su copia Snapshot e dei backup dei log, inclusa la manutenzione del catalogo di backup. Il plug-in SnapCenter per SAP HANA consente inoltre di eseguire un controllo dell'integrità del blocco del database SAP HANA eseguendo un backup basato su file.
È possibile eseguire il backup dei log del database direttamente sullo storage secondario utilizzando un montaggio NFS, come illustrato nella figura seguente.
I backup Snapshot basati su storage offrono vantaggi significativi rispetto ai backup convenzionali basati su file. Questi vantaggi includono, a titolo esemplificativo e non esaustivo, i seguenti:
-
Backup più rapido (pochi minuti)
-
RTO (Recovery Time Objective) ridotto grazie a un tempo di ripristino molto più rapido sul layer di storage (pochi minuti) e a backup più frequenti
-
Nessuna riduzione delle performance dell'host, della rete o dello storage del database SAP HANA durante le operazioni di backup e recovery
-
Replica efficiente in termini di spazio e larghezza di banda sullo storage secondario in base alle modifiche dei blocchi
Per informazioni dettagliate sulla soluzione di backup e ripristino SAP HANA con SnapCenter, consultare "TR-4614: Backup e ripristino SAP HANA con SnapCenter".
Disaster recovery SAP HANA
Il disaster recovery SAP HANA può essere eseguito a livello di database utilizzando la replica di sistema SAP HANA o a livello di storage utilizzando le tecnologie di replica dello storage. La sezione seguente fornisce una panoramica delle soluzioni di disaster recovery basate sulla replica dello storage.
Per informazioni dettagliate sulle soluzioni di disaster recovery SAP HANA, vedere "TR-4646: Disaster recovery SAP HANA con replica dello storage".
Replica dello storage basata su SnapMirror
La figura seguente mostra una soluzione di disaster recovery a tre siti che utilizza la replica sincrona di SnapMirror nel data center di disaster recovery locale e SnapMirror asincrono per replicare i dati nel data center di disaster recovery remoto.
La replica dei dati con SnapMirror sincrono fornisce un RPO pari a zero. La distanza tra il data center principale e quello locale per il disaster recovery è limitata a circa 100 km.
La protezione dai guasti del sito di disaster recovery primario e locale viene eseguita replicando i dati in un terzo data center di disaster recovery remoto utilizzando SnapMirror asincrono. L'RPO dipende dalla frequenza degli aggiornamenti di replica e dalla velocità di trasferimento. In teoria, la distanza è illimitata, ma il limite dipende dalla quantità di dati da trasferire e dalla connessione disponibile tra i data center. I valori RPO tipici sono compresi nell'intervallo da 30 minuti a più ore.
L'RTO per entrambi i metodi di replica dipende principalmente dal tempo necessario per avviare il database HANA nel sito di disaster recovery e caricare i dati in memoria. Supponendo che i dati siano letti con un throughput di 1000 Mbps, il caricamento di 1 TB di dati richiederebbe circa 18 minuti.
I server dei siti di disaster recovery possono essere utilizzati come sistemi di sviluppo/test durante il normale funzionamento. In caso di disastro, i sistemi di sviluppo/test devono essere spenti e avviati come server di produzione per il disaster recovery.
Entrambi i metodi di replica consentono di eseguire test del workflow di disaster recovery senza influenzare RPO e RTO. I volumi FlexClone vengono creati sullo storage e collegati ai server di test del disaster recovery.
La replica sincrona offre la modalità StrictSync. Se la scrittura sullo storage secondario non viene completata per qualsiasi motivo, l'i/o dell'applicazione non riesce, garantendo così che i sistemi di storage primario e secondario siano identici. L'i/o dell'applicazione al primario riprende solo dopo che la relazione SnapMirror ritorna allo stato InSync. In caso di guasto dello storage primario, l'i/o dell'applicazione può essere ripristinato sullo storage secondario dopo il failover, senza perdita di dati. In modalità StrictSync, l'RPO è sempre zero.
Replica dello storage basata su MetroCluster
La figura seguente mostra una panoramica di alto livello della soluzione. Il cluster di storage di ogni sito fornisce alta disponibilità locale e viene utilizzato per il carico di lavoro di produzione. I dati di ciascun sito vengono replicati in modo sincrono nell'altra posizione e sono disponibili in caso di failover di emergenza.
