Best Practice
Architettura
Suggerisci modifiche
PDF
Gli host SAP HANA sono connessi ai controller di storage utilizzando un'infrastruttura FCP ridondante e un software multipath. È necessaria un'infrastruttura di switch FCP ridondante per fornire connettività host-to-storage SAP HANA fault-tolerant in caso di guasto dello switch o dell'HBA (host bus adapter). È necessario configurare lo zoning appropriato sullo switch per consentire a tutti gli host HANA di raggiungere i LUN richiesti sui controller di storage.
È possibile utilizzare diversi modelli della famiglia di prodotti FAS a livello di storage. Il numero massimo di host SAP HANA collegati allo storage è definito dai requisiti di performance SAP HANA. Il numero di shelf di dischi richiesti è determinato 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 ha di storage.
Questa architettura può essere scalata in due dimensioni:
-
Collegando ulteriori host SAP HANA e capacità del disco allo storage, supponendo che i controller dello storage possano fornire performance sufficienti sotto il nuovo carico per soddisfare i principali indicatori di performance (KPI)
-
Aggiungendo più sistemi storage e capacità disco per gli host SAP HANA aggiuntivi
La figura seguente mostra un esempio di configurazione 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 dei 16 host SAP HANA. A seconda dei requisiti di throughput totale, è necessario aggiungere ulteriori connessioni FC ai controller di storage.
Indipendentemente dal modello di storage del sistema FAS implementato, il panorama SAP HANA può anche essere scalato aggiungendo più controller di storage, come illustrato nella figura seguente.
Backup SAP HANA
Il software NetApp ONTAP offre un meccanismo integrato per il backup dei database SAP HANA. Il backup Snapshot basato su storage è una soluzione di backup completamente supportata e integrata disponibile per i sistemi single-container SAP HANA e per i sistemi single-tenant SAP HANA MDC.
I backup Snapshot basati su storage vengono implementati utilizzando il plug-in NetApp SnapCenter per SAP HANA, che consente backup Snapshot coerenti basati su storage utilizzando le interfacce fornite dal database SAP HANA. SnapCenter registra i backup Snapshot nel catalogo di backup SAP HANA in modo che i backup siano visibili all'interno di SAP HANA Studio e possano essere selezionati per le operazioni di ripristino e ripristino.
Utilizzando il software NetApp SnapVault, le copie Snapshot create sullo storage primario possono essere replicate nello storage di backup secondario controllato da SnapCenter. È possibile definire diverse policy di conservazione dei backup per i backup sullo storage primario e per i backup sullo storage secondario. Il plug-in SnapCenter per il database SAP HANA gestisce 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 database SAP HANA consente inoltre di eseguire un controllo dell'integrità dei blocchi 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 basati su file. Tali vantaggi includono:
-
Backup più rapido (pochi minuti)
-
Ripristino più rapido sul layer di storage (pochi minuti)
-
Nessun effetto sulle prestazioni dell'host, della rete o dello storage del database SAP HANA durante il backup
-
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, vedere "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 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 sulla soluzione di disaster recovery SAP HANA con SnapCenter, 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 DR locale e SnapMirror asincrono per replicare i dati nel data center di DR remoto.
La replica dei dati con SnapMirror sincrono fornisce un RPO pari a zero. La distanza tra il data center DR principale e quello locale è limitata a circa 100 km.
La protezione dai guasti del sito di DR primario e locale viene eseguita replicando i dati in un terzo data center di DR 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 DR 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 DR 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 DR.
Entrambi i metodi di replica consentono di eseguire test del workflow di DR senza influenzare l'RPO e l'RTO. I volumi FlexClone vengono creati sullo storage e collegati ai server di test del DR.
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 NetApp MetroCluster
La figura seguente mostra una panoramica di alto livello della soluzione. Il cluster di storage di ogni sito offre alta disponibilità locale e viene utilizzato per i carichi 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.
