Best Practice
Dimensionamento dello storage
Suggerisci modifiche
PDF
La sezione seguente fornisce una panoramica delle considerazioni su performance e capacità per il dimensionamento di un sistema storage per SAP HANA.
|
Contatta il tuo commerciale NetApp o il tuo partner NetApp per supportare il processo di dimensionamento dello storage e creare un ambiente di storage di dimensioni adeguate. |
Considerazioni sulle performance
SAP ha definito un set statico di KPI relativi allo storage. Questi KPI sono validi per tutti gli ambienti SAP HANA in produzione, indipendentemente dalle dimensioni della memoria degli host di database e delle applicazioni che utilizzano il database SAP HANA. Questi KPI sono validi per ambienti a host singolo, host multiplo, Business Suite su HANA, Business Warehouse su HANA, S/4HANA e BW/4HANA. Pertanto, l'attuale approccio al dimensionamento delle performance dipende solo dal numero di host SAP HANA attivi collegati al sistema storage.
|
|
I KPI relativi alle performance dello storage sono richiesti solo per i sistemi SAP HANA in produzione. |
SAP offre uno strumento di test delle performance, che deve essere utilizzato per validare le performance dello storage per gli host SAP HANA attivi collegati allo storage.
NetApp ha testato e predefinito il numero massimo di host SAP HANA che possono essere collegati a un modello di storage specifico, pur continuando a soddisfare i KPI di storage richiesti da SAP per i sistemi SAP HANA basati sulla produzione.
|
|
I controller di storage della famiglia di prodotti certificati FAS possono essere utilizzati anche per SAP HANA con altri tipi di dischi o soluzioni di back-end su disco, purché siano supportati da NetApp e soddisfino i KPI relativi alle performance di SAP HANA TDI. Ad esempio, NetApp Storage Encryption (NSE) e la tecnologia NetApp FlexArray. |
Questo documento descrive il dimensionamento dei dischi rigidi SAS e dei dischi a stato solido.
Dischi rigidi
Per soddisfare i KPI relativi alle performance di storage di SAP, è necessario un minimo di 10 dischi dati (SAS a 10.000 rpm) per nodo SAP HANA.
|
|
Questo calcolo è indipendente dal controller di storage e dallo shelf di dischi utilizzati. |
Dischi a stato solido
Con i dischi a stato solido (SSD), il numero di dischi dati è determinato dal throughput della connessione SAS dai controller di storage allo shelf SSD.
Il numero massimo di host SAP HANA che possono essere eseguiti su uno shelf di dischi e il numero minimo di SSD richiesti per host SAP HANA sono stati determinati eseguendo il tool di test delle performance SAP.
-
Lo shelf di dischi SAS da 12 GB (DS224C) con 24 SSD supporta fino a 14 host SAP HANA, quando lo shelf di dischi è collegato a 12 GB.
-
Lo shelf di dischi SAS da 6 GB (DS2246) con 24 SSD supporta fino a 4 host SAP HANA.
Gli SSD e gli host SAP HANA devono essere equamente distribuiti tra entrambi i controller di storage.
La seguente tabella riassume il numero di host SAP HANA supportati per shelf di dischi.
| Shelf SAS da 6 GB (DS2246) completamente caricati con 24 SSD | Shelf SAS da 12 GB (DS224C) completamente caricati con 24 SSD | |
|---|---|---|
Numero massimo di host SAP HANA per shelf di dischi |
4 |
14 |
|
|
Questo calcolo è indipendente dal controller di storage utilizzato. L'aggiunta di più shelf di dischi non aumenta il numero massimo di host SAP HANA supportati da uno storage controller. |
Carichi di lavoro misti
Sono supportati SAP HANA e altri carichi di lavoro applicativi eseguiti sullo stesso storage controller o nello stesso aggregato di storage. Tuttavia, è una Best practice di NetApp separare i workload SAP HANA da tutti gli altri workload delle applicazioni.
Potresti decidere di implementare workload SAP HANA e altri workload applicativi sullo stesso storage controller o sullo stesso aggregato. In tal caso, è necessario assicurarsi che siano sempre disponibili performance sufficienti per SAP HANA all'interno dell'ambiente di workload misto. NetApp consiglia inoltre di utilizzare i parametri della qualità del servizio (QoS) per regolare l'impatto che queste altre applicazioni potrebbero avere sulle applicazioni SAP HANA.
Il tool di test SAP HCMT deve essere utilizzato per verificare se è possibile eseguire altri host SAP HANA su uno storage controller già utilizzato per altri carichi di lavoro. Tuttavia, i server applicativi SAP possono essere posizionati in modo sicuro sullo stesso storage controller e aggregati dei database SAP HANA.
Considerazioni sulla capacità
Una descrizione dettagliata dei requisiti di capacità per SAP HANA è disponibile nella "Nota SAP 1900823" white paper.
|
|
Il dimensionamento della capacità del panorama SAP complessivo con più sistemi SAP HANA deve essere determinato utilizzando gli strumenti di dimensionamento dello storage SAP HANA di NetApp. Contatta NetApp o il tuo partner commerciale NetApp per convalidare il processo di dimensionamento dello storage per un ambiente di storage di dimensioni adeguate. |
Configurazione dello strumento di test delle performance
A partire da SAP HANA 1.0 SPS10, SAP ha introdotto i parametri per regolare il comportamento di i/o e ottimizzare il database per il file e il sistema storage utilizzati. Questi parametri devono essere impostati anche per lo strumento di test delle performance di SAP (fsperf) quando le performance dello storage vengono testate utilizzando lo strumento di test SAP.
I test delle performance sono stati condotti da NetApp per definire i valori ottimali. La seguente tabella elenca i parametri che devono essere impostati nel file di configurazione dello strumento di test SAP.
| Parametro | Valore |
|---|---|
max_parallel_io_requests |
128 |
async_read_submit |
acceso |
async_write_submit_active |
acceso |
async_write_submit_blocks |
tutto |
Per ulteriori informazioni sulla configurazione dello strumento di test SAP, vedere "Nota SAP 1943937" Per HWCCT (SAP HANA 1.0) e. "Nota SAP 2493172" PER HCMT/HCOT (SAP HANA 2.0).
Nell'esempio seguente viene illustrato come impostare le variabili per il piano di esecuzione HCMT/HCOT.
…{
"Comment": "Log Volume: Controls whether read requests are submitted asynchronously, default is 'on'",
"Name": "LogAsyncReadSubmit",
"Value": "on",
"Request": "false"
},
{
"Comment": "Data Volume: Controls whether read requests are submitted asynchronously, default is 'on'",
"Name": "DataAsyncReadSubmit",
"Value": "on",
"Request": "false"
},
{
"Comment": "Log Volume: Controls whether write requests can be submitted asynchronously",
"Name": "LogAsyncWriteSubmitActive",
"Value": "on",
"Request": "false"
},
{
"Comment": "Data Volume: Controls whether write requests can be submitted asynchronously",
"Name": "DataAsyncWriteSubmitActive",
"Value": "on",
"Request": "false"
},
{
"Comment": "Log Volume: Controls which blocks are written asynchronously. Only relevant if AsyncWriteSubmitActive is 'on' or 'auto' and file system is flagged as requiring asynchronous write submits",
"Name": "LogAsyncWriteSubmitBlocks",
"Value": "all",
"Request": "false"
},
{
"Comment": "Data Volume: Controls which blocks are written asynchronously. Only relevant if AsyncWriteSubmitActive is 'on' or 'auto' and file system is flagged as requiring asynchronous write submits",
"Name": "DataAsyncWriteSubmitBlocks",
"Value": "all",
"Request": "false"
},
{
"Comment": "Log Volume: Maximum number of parallel I/O requests per completion queue",
"Name": "LogExtMaxParallelIoRequests",
"Value": "128",
"Request": "false"
},
{
"Comment": "Data Volume: Maximum number of parallel I/O requests per completion queue",
"Name": "DataExtMaxParallelIoRequests",
"Value": "128",
"Request": "false"
}, …
Queste variabili devono essere utilizzate per la configurazione del test. Questo è solitamente il caso dei piani di esecuzione predefiniti che SAP offre con lo strumento HCMT/HCOT. Il seguente esempio per un test di scrittura del log 4k è da un piano di esecuzione.
…
{
"ID": "D664D001-933D-41DE-A904F304AEB67906",
"Note": "File System Write Test",
"ExecutionVariants": [
{
"ScaleOut": {
"Port": "${RemotePort}",
"Hosts": "${Hosts}",
"ConcurrentExecution": "${FSConcurrentExecution}"
},
"RepeatCount": "${TestRepeatCount}",
"Description": "4K Block, Log Volume 5GB, Overwrite",
"Hint": "Log",
"InputVector": {
"BlockSize": 4096,
"DirectoryName": "${LogVolume}",
"FileOverwrite": true,
"FileSize": 5368709120,
"RandomAccess": false,
"RandomData": true,
"AsyncReadSubmit": "${LogAsyncReadSubmit}",
"AsyncWriteSubmitActive": "${LogAsyncWriteSubmitActive}",
"AsyncWriteSubmitBlocks": "${LogAsyncWriteSubmitBlocks}",
"ExtMaxParallelIoRequests": "${LogExtMaxParallelIoRequests}",
"ExtMaxSubmitBatchSize": "${LogExtMaxSubmitBatchSize}",
"ExtMinSubmitBatchSize": "${LogExtMinSubmitBatchSize}",
"ExtNumCompletionQueues": "${LogExtNumCompletionQueues}",
"ExtNumSubmitQueues": "${LogExtNumSubmitQueues}",
"ExtSizeKernelIoQueue": "${ExtSizeKernelIoQueue}"
}
}, …
Panoramica del processo di dimensionamento dello storage
Il numero di dischi per host HANA e la densità host SAP HANA per ciascun modello di storage sono stati determinati con il tool di test SAP HANA.
Il processo di dimensionamento richiede dettagli come il numero di host SAP HANA in produzione e non in produzione, la dimensione della RAM di ciascun host e il periodo di conservazione del backup delle copie Snapshot basate sullo storage. Il numero di host SAP HANA determina il controller dello storage e il numero di dischi necessari.
Le dimensioni della RAM, le dimensioni nette dei dati sul disco di ciascun host SAP HANA e il periodo di conservazione del backup delle copie Snapshot vengono utilizzati come input durante il dimensionamento della capacità.
La figura seguente riassume il processo di dimensionamento.
