La deduplica inline, la deduplica inline di più volumi, la compressione inline e la compaction inline sono supportate con SAP HANA in una configurazione SSD.

L'utilizzo dei volumi NetApp FlexGroup non è supportato per SAP HANA. Grazie all'architettura di SAP HANA l'utilizzo di FlexGroup Volumes non fornisce alcun beneficio e potrebbe causare problemi di performance.

L'utilizzo di NetApp Volume Encryption (NVE) e NetApp aggregate Encryption (NAE) sono supportati con SAP HANA.

La QoS può essere utilizzata per limitare il throughput dello storage per specifici sistemi SAP HANA o applicazioni no-SAP su un controller condiviso. Un caso d'utilizzo sarebbe quello di limitare il throughput dei sistemi di sviluppo e test in modo che non possano influenzare i sistemi di produzione in una configurazione mista.

Durante il processo di dimensionamento, è necessario determinare i requisiti di performance di un sistema non in produzione. I sistemi di sviluppo e test possono essere dimensionati con valori di performance inferiori, in genere nell'intervallo compreso tra il 20% e il 50% di un KPI del sistema di produzione come definito da SAP.

A partire da ONTAP 9, la qualità del servizio viene configurata a livello di volume di storage e utilizza i valori massimi per il throughput (Mbps) e la quantità di i/o (IOPS).

L'i/o di scrittura di grandi dimensioni ha il maggiore effetto sulle performance del sistema storage. Pertanto, il limite di throughput QoS deve essere impostato su una percentuale dei corrispondenti valori KPI di scrittura delle performance dello storage SAP HANA nei volumi di dati e di log.

La tecnologia NetApp FabricPool non deve essere utilizzata per i file system primari attivi nei sistemi SAP HANA. Sono inclusi i file system per l'area dei dati e dei log, oltre a /hana/shared file system. In questo modo si ottengono performance imprevedibili, in particolare durante l'avvio di un sistema SAP HANA.

È possibile utilizzare il criterio di tiering Snapshot-Only insieme a FabricPool in una destinazione di backup come SnapVault o SnapMirror.

FabricPool è un'ottima opzione per spostare i backup dei log in un altro Tier di storage. Lo spostamento dei backup influisce sul tempo necessario per ripristinare un database SAP HANA. Pertanto, l'opzione tiering-minimum-cooling-days deve essere impostato su un valore che colloca i backup dei log, normalmente necessari per il ripristino, nel tier di storage locale fast.

La seguente panoramica riassume i passaggi necessari per la configurazione dello storage. Ogni fase viene descritta in maggiore dettaglio nelle sezioni successive. In questa sezione, si presuppone che l'hardware di storage sia configurato e che il software ONTAP sia già installato. Inoltre, la connessione delle porte FCP dello storage al fabric SAN deve essere già attiva.

In generale, è necessario configurare due aggregati per controller, indipendentemente da quale shelf di dischi o tecnologia di dischi (SSD o HDD) viene utilizzata. Questo passaggio è necessario per poter utilizzare tutte le risorse del controller disponibili. Per i sistemi della serie AFF A200, è sufficiente un aggregato di dati.

La figura seguente mostra una configurazione di 12 host SAP HANA in esecuzione su uno shelf SAS da 12 GB configurato con ADPv2. Sei host SAP HANA sono collegati a ciascun controller di storage. Sono configurati quattro aggregati separati, due per ogni controller di storage. Ogni aggregato è configurato con 11 dischi con nove partizioni di dati e due di dischi di parità. Per ciascun controller sono disponibili due partizioni di riserva.

Diversi ambienti SAP con database SAP HANA possono utilizzare una singola SVM. È possibile assegnare una SVM a ciascun ambiente SAP, se necessario, nel caso in cui sia gestita da diversi team all'interno di un'azienda.

Se viene creato e assegnato automaticamente un profilo QoS durante la creazione di una nuova SVM, rimuovere questo profilo creato automaticamente dalla SVM per garantire le prestazioni richieste per SAP HANA:

All'interno della configurazione del cluster di storage, è necessario creare un'interfaccia di rete (LIF) e assegnarla a una porta FCP dedicata. Se, ad esempio, sono necessarie quattro porte FCP per motivi di performance, è necessario creare quattro LIF. La figura seguente mostra una schermata delle otto LIF (denominate fc_*_*) configurati su hana SVM.

Durante la creazione di SVM con Gestore di sistema di ONTAP 9.8, è possibile selezionare tutte le porte FCP fisiche richieste e creare automaticamente una LIF per porta fisica.

Un set di porte FCP viene utilizzato per definire quali LIF devono essere utilizzate da uno specifico gruppo di iniziatori. In genere, tutte le LIF create per i sistemi HANA vengono inserite nello stesso set di porte. La figura seguente mostra la configurazione di un set di porte denominato 32g che include le quattro LIF già create.

La figura seguente mostra la configurazione dei volumi di quattro sistemi SAP HANA a host singolo. I volumi di dati e log di ciascun sistema SAP HANA vengono distribuiti a diversi storage controller. Ad esempio, volume SID1_data_mnt00001 È configurato sul controller A e sul volume SID1_log_mnt00001 È configurato sul controller B. All'interno di ciascun volume viene configurato un singolo LUN.

Per ogni host SAP HANA, un volume di dati, un volume di log e un volume per /hana/shared sono configurati. La seguente tabella mostra una configurazione di esempio con quattro sistemi SAP HANA a host singolo.

La seguente tabella mostra un esempio di configurazione del punto di montaggio per un sistema a host singolo.

Linux LVM può essere utilizzato per aumentare le performance e risolvere i limiti delle dimensioni del LUN. Le diverse LUN di un gruppo di volumi LVM devono essere memorizzate in un aggregato diverso e in un controller diverso. La seguente tabella mostra un esempio di due LUN per gruppo di volumi.

Nell'host SAP HANA, è necessario creare e montare gruppi di volumi e volumi logici, come indicato nella tabella seguente.

La figura seguente mostra la configurazione di un volume di un sistema SAP HANA 4+1 multihost. I volumi di dati e i volumi di log di ciascun host SAP HANA vengono distribuiti a diversi storage controller. Ad esempio, il volume SID_data_mnt00001 È configurato sul controller A e sul volume SID_log_mnt00001 È configurato sul controller B. Viene configurato un LUN per ciascun volume.

Il /hana/shared Il volume deve essere accessibile da tutti gli host HANA e viene quindi esportato utilizzando NFS. Anche se non sono disponibili KPI specifici per le performance per /hana/shared File system, NetApp consiglia di utilizzare una connessione Ethernet a 10 GB.

Per ogni host SAP HANA, vengono creati un volume di dati e un volume di log. Il /hana/shared Il volume viene utilizzato da tutti gli host del sistema SAP HANA. La seguente tabella mostra una configurazione di esempio per un sistema SAP HANA 4+1 a host multiplo.

La seguente tabella mostra la configurazione e i punti di montaggio di un sistema a più host con quattro host SAP HANA attivi.

Linux LVM può essere utilizzato per aumentare le performance e risolvere i limiti delle dimensioni del LUN. Le diverse LUN di un gruppo di volumi LVM devono essere memorizzate in un aggregato diverso e in un controller diverso.

La seguente tabella mostra un esempio di due LUN per gruppo di volumi per un sistema host multiplo SAP HANA 2+1.

Nell'host SAP HANA, è necessario creare e montare gruppi di volumi e volumi logici, come indicato nella tabella seguente.

Le opzioni dei volumi elencate nella tabella seguente devono essere verificate e impostate su tutte le SVM.

Questa sezione mostra un esempio di configurazione utilizzando la riga di comando con ONTAP 9.8 per un sistema host 2+1 SAP HANA con SID FC5 utilizzando LVM e due LUN per gruppo di volumi LVM: