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.
Diversi modelli della famiglia di sistemi AFF 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 ha di storage.
Questa architettura può essere scalata in due dimensioni:
-
Collegando ulteriori host SAP HANA e capacità di storage allo storage esistente, se i controller di storage forniscono performance sufficienti per soddisfare gli attuali KPI SAP HANA
-
Aggiungendo altri sistemi storage con capacità di storage aggiuntiva 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 sistema AFF implementato, il panorama SAP HANA può anche essere scalato aggiungendo qualsiasi storage controller certificato per soddisfare la densità di nodo desiderata, come mostrato nella 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 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 o 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 anche 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 ridotto grazie a tempi di ripristino molto più rapidi 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, 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 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 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.
