best practice per la configurazione dello storage

Transcript

Guida alla soluzione
BEST PRACTICE PER LA CONFIGURAZIONE DELLO
STORAGE PER SAP HANA TAILORED DATA CENTER
INTEGRATION SU EMC VMAX
 VMAX 10K, 20K, 40K
 VMAX3 100K, 200K, 400K
 VMAX All Flash 250F/FX, 450F/FX, 850F/FX
Soluzioni EMC
Abstract
Questa guida alla soluzione descrive un concetto che consente di superare le
limitazioni imposte dal modello SAP HANA (High Performance Analytical Appliance).
Utilizzando la tecnologia TDI (Tailored Data Center Integration) su sistemi di storage
EMC® VMAX® , VMAX3TM e VMAX® All-Flash , i clienti possono integrare HANA in
un'infrastruttura di data center esistente e consolidata e usufruire cosìdi molteplici
vantaggi.
Ottobre 2016
Copyright
Copyright © 2016 EMC Corporation. Tutti i diritti riservati. Pubblicato in Italia.
Data di pubblicazione: ottobre 2016
EMC ritiene che le informazioni contenute in questo documento siano esatte al momento della sua data di
pubblicazione. Le informazioni sono soggette a modifica senza preavviso.
Le informazioni contenute nella presente documentazione vengono fornite "cosìcome sono". EMC
Corporation non riconosce garanzie di alcun genere inerenti le informazioni riportate nella presente
pubblicazione, tra cui garanzie implicite di commerciabilità o idoneità a un determinato scopo. L'utilizzo, la
copia e la distribuzione dei prodotti EMC descritti in questo documento richiedono una licenza valida per
ciascun software.
EMC2, EMC, Data Domain, VMAX, VMAX3, VMAX All Flash, Provisioning virtuale e il logo EMC sono marchi
registrati o marchi di EMC Corporation negli Stati Uniti e in altri Paesi. Tutti gli altri marchi citati nel
presente documento appartengono ai rispettivi proprietari.
Per un elenco aggiornato dei nomi di prodotti di EMC, vedere la sezione Marchi di EMC Corporation sul sito
web emc.com.
Best practice per la configurazione dello storage per SAP HANA Tailored Data Center Integration (TDI) su EMC VMAX
Part Number XXXX
Dichiarazione di non responsabilità. Il contenuto del presente documento potrebbe essere diverso
dal contenuto del documento pubblicato.
2
Best practice per la configurazione dello storage per SAP HANA TDI su EMC VMAX
Sommario
Sommario
Executive Summary ...............................................................................................................................4
Introduzione ..........................................................................................................................................6
Utilizzo di array EMC VMAX per SAP HANA: considerazioni generali ......................................................7
Principi di progettazione dello storage per SAP HANA su array VMAX (10K, 20K, 40K) ...................... 13
Principi di progettazione dello storage per SAP HANA su array VMAX3 e VMAX All Flash (100K, 200K,
400K, 250F/FX, 450F/FX, 850F/FX) ..................................................................................................... 17
Installazione e configurazione dello storage di un cluster scale-out HANA in un array VMAX All-Flash:
Esempio ............................................................................................................................................. 22
Conclusioni ........................................................................................................................................ 37
Riferimenti ......................................................................................................................................... 38
3
Executive Summary
Executive Summary
Business case
SAP HANA è una piattaforma In-memory che può essere implementata a livello locale
(on-premise) o nel cloud. È una piattaforma rivoluzionaria particolarmente indicata
per l'esecuzione di analisi in tempo reale e lo sviluppo e l'implementazione di
applicazioni in tempo reale. Il fulcro di questa piattaforma di dati in tempo reale è
costituito dal database HANA.
HANA combina componenti software SAP ottimizzati su prodotti hardware comprovati
messi a disposizione da partner SAP. Può essere configurata in locale adottando uno
due modelli illustrati nella Figura 1.
Figura 1.
Confronto tra il modello di appliance SAP HANA e il modello TDI (immagine
© SAP SE)
Per impostazione predefinita, un appliance HANA include componenti di storage, di
elaborazione e di rete integrati. L'appliance è certificato da SAP, realizzato da uno dei
partner HANA per l'hardware e spedito ai clienti con tutti i componenti software
preinstallati, inclusi i sistemi operativi e il software HANA.
L'approccio TDI è più aperto rispetto al modello di implementazione dell'appliance e
garantisce maggiore flessibilità. I server HANA devono ancora soddisfare i requisiti di
HANA e ottenere la certificazione di server HANA, mentre i componenti di rete e
storage possono essere condivisi negli ambienti dei clienti. I clienti, quindi, possono
utilizzare gli enterprise storage array esistenti per HANA e integrare la piattaforma
HANA in modo trasparente nelle operazioni esistenti dei data center (ad esempio,
disaster recovery, protezione dei dati, monitoraggio e gestione), riducendo cosìil
time-to-value e i rischi e i costi di un'adozione HANA complessiva.
Solution overview
SAP certifica gli enterprise storage array utilizzati nelle implementazioni HANA TDI per
garantire che soddisfino i requisiti funzionali e di prestazioni di HANA1. Utilizzando lo
strumento HANA Hardware Configuration Check Tool (hwcct), EMC ha eseguito test
1
4
Gli array EMC VMAX, VMAX3 e VMAX All-Flash sono certificati da SAP.
Executive Summary
approfonditi sulla famiglia EMC® VMAX® e i sistemi di storage VMAX® All Flash in
conformità ai seguenti scenari di certificazione SAP:

HANA-HWC-ES 1.0  per VMAX

HANA-HWC-ES-1.1  per VMAX3TM e VMAX All-Flash
Sulla base dei risultati dei test, questa guida alla soluzione descrive le configurazioni
di storage consigliate per gli array VMAX, VMAX3 e VMAX All-Flash, in grado di
soddisfare i requisiti di prestazioni SAP (ovvero, i key performance indicator di SAP
HANA TDI per la latenza e il throughput dei dati) e di garantire i massimi livelli di
disponibilità per la persistenza del database sul disco.
Nota: SAP consiglia ai clienti TDI di eseguire lo strumento hwcct nel proprio ambiente per
accertarsi che la specifica implementazione di HANA TDI in uso soddisfi i criteri di
prestazioni SAP.
Questa guida alla soluzione descrive le implementazioni di HANA TDI in ambienti
fisici. Se si intende utilizzare HANA in ambienti virtualizzati VMware su vSphere, fare
riferimento al documento EMC Guida alla soluzione SAP HANA nell'ambiente
virtualizzato VMware con storage EMC.
Vantaggi principali I clienti che utilizzano HANA TDI su sistemi VMAX, VMAX3 e VMAX All-Flash possono:
La tua opinione è
importante

Integrare HANA in un data center esistente

Utilizzare l'enterprise storage condiviso VMAX per affidarsi a concetti già
disponibili per la gestione su più siti allo scopo di trarre vantaggi concreti da
processi operativi e di automazione consolidati

Effettuare facilmente la transizione da un modello basato su appliance a
un'architettura TDI basata su VMAX, affidandosi ai servizi EMC per ridurre al
minimo i rischi

Utilizzare i processi operativi, le competenze e gli strumenti esistenti per
evitare i rischi e i costi significativi associati alle modifiche operative

Sfruttare le prestazioni e i vantaggi di scalabilità offerti da VMAX per ottenere
informazioni in tempo reale a livello aziendale
EMC e gli autori del presente documento sono lieti di conoscere l'opinione dei propri
clienti sulla soluzione e sulla documentazione associata alla soluzione. Invia la tua
opinione all'indirizzo [email protected].
Autori: Werner Katzenberger, Aighne Kearney
5
Introduzione
Introduzione
Scopo della
soluzione
Prima che venisse introdotto il modello di implementazione HANA TDI, i clienti
adottavano il modello di appliance, che presentava le seguenti limitazioni:

Scelta limitata di server, reti e storage

Impossibilità di utilizzare l'infrastruttura del data center e processi operativi
esistenti

Dimensioni fisse relativamente alle capacità di storage HANA (lo storage era
parte integrante dell'appliance)

Controllo e conoscenza insufficienti dei componenti critici dell'appliance
HANA

Dimensioni fisse per le capacità dello storage e dei server HANA, con un
conseguente aumento dei costi determinato dalla mancanza di capacità e
dall'impossibilità di rispondere tempestivamente a un incremento imprevisto
delle richieste
Questa guida descrive una soluzione che utilizza HANA in uno scenario di
implementazione TDI su enterprise storage VMAX, VMAX3 e VMAX All-Flash. Questa
soluzione contribuisce a ridurre i costi hardware e operativi, a limitare i rischi e ad
aumentare la flessibilità dei vendor di server e rete.
La guida offre anche suggerimenti di configurazione messi a punto a partire dai
requisiti SAP per l'high availability e dai risultati dei test sulle prestazioni richiesti per
soddisfare i key performance indicator di SAP per HANA TDI.
Ambito
Audience
6
Questo documento fornisce le seguenti informazioni:

Best practice e suggerimenti per l'implementazione del database HANA su
sistemi di storage VMAX, VMAX3 e VMAX All-Flash

Introduzione alle principali tecnologie della soluzione

Descrizione dei requisiti di configurazione e dei principi di progettazione
relativi ai sistemi di storage VMAX, VMAX3 e VMAX All-Flash con HANA

Esempio di un'installazione scale-out di HANA utilizzando storage device
VMAX All-Flash
Questo documento è rivolto a system integrator, System e Storage Administrator,
clienti, partner e membri di EMC Professional Services che devono configurare uno
storage array VMAX, VMAX3 o VMAX All-Flash da utilizzare in un ambiente TDI per
HANA.
Utilizzo di array EMC VMAX per SAP HANA: considerazioni generali
In questa sezione sono disponibili considerazioni generali di cui è opportuno tener
conto quando si collega HANA ad array VMAX. Mentre le considerazioni sulla
configurazione di dischi, pool e LUN variano tra i sistemi VMAX e i sistemi VMAX3 e
VMAX All-Flash, quelle riportate di seguito sono comuni a tutte le piattaforme:

Requisiti di capacità HANA

Considerazioni sulla rete SAN

Modelli di I/O di HANA

Considerazioni sulla replica di storage con SRDF
La certificazione SAP HANA per l'enterprise storage non utilizza gli stessi scenari di
certificazione per VMAX (10K, 20K, 40K) degli array VMAX3 e VMAX All Flash. Questa
sezione illustra quali sono le differenze.
Requisiti di
capacità HANA
Ogni nodo HANA richiede capacità e storage device per gli elementi seguenti:

Immagine di avvio del sistema operativo

Installazione di HANA

Persistenza di HANA (dati e log)

Backup
Se l'avvio dei nodi HANA viene eseguito da un volume sull'array VMAX (ovvero da
Storage Area Network o SAN), la capacità richiesta per il sistema operativo deve
essere inclusa nel calcolo della capacità complessiva per l'installazione di HANA.
Ogni nodo HANA richiede circa 100 GB di capacità per il sistema operativo, inclusa la
directory /usr/sap/.
In caso di avvio da una rete SAN, seguire le best practice descritte nella sezione
"Avvio da SAN" del documento Guida alla connettività host di EMC per Linux.
Installazione di HANA (/hana/shared/)
Ogni nodo HANA richiede l'accesso a un file system di cui è stato eseguito il mount in
un mount point locale, /hana/shared/, per consentire l'installazione dei file binari
HANA e dei file di configurazione, delle tracce e dei log. In un cluster scale-out HANA,
inoltre, è necessario un singolo file system condiviso, di cui deve essere eseguito il
mount in tutti i nodi. La maggior parte delle installazioni di HANA utilizza un file
system NFS per soddisfare questo requisito. Gli array VMAX3 e VMAX All-Flash offrono
questo file system con l'opzione eNAS. È possibile calcolare la dimensione del file
system /hana/shared/ utilizzando la formula illustrata nel White paper relativo ai
requisiti di storage di SAP HANA. La versione 2.7 di questo documento (febbraio
2016) utilizza le formule seguenti:
7
Nodo singolo (scale-up):
Dimensioneinstallazione(singolo nodo) = MIN(1 RAM; 1 TB)
Più nodi (scale-out):
Dimensioneinstallazione(scale-out) = 1 RAM_of_worker per 4 nodi worker
Persistenza di HANA (dati e log)
Il database In-memory HANA richiede storage su disco per i motivi seguenti:

Per mantenere la persistenza dei dati In-memory sul disco, in modo da evitare
perdite di dati in caso di interruzione dell'alimentazione e consentire il
failover automatico degli host, in cui un host HANA in standby acquisisce i
dati In-memory di un worker host guasto in installazioni di tipo scale-out

Per registrare informazioni sulle modifiche ai dati (redo log)
Per ogni nodo HANA (scale-up) e ogni nodo worker (scale-out) sono necessari due
disk volume, in modo da poter salvare il database In-memory sul disco (dati) e
mantenere un redo log (log). La dimensione di questi volumi dipende dal requisito di
memoria totale prevista del database e dalla dimensione della RAM del nodo. Per
consentire gli utenti di predisporre un disco delle dimensioni corrette, nel White
paper relativo ai requisiti di storage di SAP HANA SAN ha pubblicato riferimenti agli
strumenti e ai documenti pertinenti. La versione 2.7 del documento, pubblicata a
febbraio 2016, specifica che è possibile calcolare la dimensione del volume di dati
con la formula seguente:
Dimensionedati = 1,2 volte lo spazio netto su disco per i dati
dove per spazio netto su disco si intende il requisito di memoria totale prevista
del database più un ulteriore 20% di spazio libero.
Se il database viene distribuito su più nodi in un cluster scale-out, dividere lo spazio
netto su disco per il numero di nodi worker HANA del cluster. Ad esempio, se lo
spazio netto su disco è 2 TB e il cluster scale-out è costituito da quattro nodi worker,
a ogni nodo deve essere assegnato un volume di dati da 616 GB (2 TB / 4 = 512 GB x
1,2 = 616 GB).
Se al momento di definire le dimensioni dello storage lo spazio netto su disco non è
conosciuto, EMC consiglia di calcolare la capacità del file system dei dati utilizzando
la dimensione della RAM del nodo più il 20% dello spazio libero sul disco.
La dimensione del volume di log dipende dalla dimensione della RAM del nodo. Il
White paper relativo ai requisiti di storage di SAP HANA consiglia di utilizzare le
formule seguenti per calcolare la dimensione minima del volume di log:
[sistemi ≤ 512 GB] Dimensioneredolog = 1/2 RAM
8
[sistemi > 512 GB] Dimensioneredolog(min) = 512 GB
Backup
HANA supporta il backup su un file system o l'utilizzo di strumenti di terze parti
certificati da SAP. EMC supporta strategie di protezione dei dati per il backup di HANA
utilizzando EMC Data Domain® e Networker® . Sebbene sia possibile eseguire il
backup di HANA su un file system NFS in un array VMAX3 o VMAX All Flash, EMC
sconsiglia il backup del database di HANA sullo stesso storage array in cui risiede la
persistenza primaria. Se si intende eseguire il backup di HANA su un file system NFS
in un array VMAX3 o VMAX All Flash diverso, fare riferimento al white paper sui
requisiti di storage di SAP per informazioni sul dimensionamento del backup file
system. La capacità dipende non solo dalla dimensione dei dati e dalla frequenza
delle operazioni di modifica del database, ma anche dalle generazioni di backup
conservate su disco.
Considerazioni
sulla rete SAN
Considerazioni generali sulla connettività SAN
La connettività SAN, che comprende HBA dell'host, porte SAN, switch e porte frontend per array, richiede un'attenta pianificazione. I KPI di SAP HANA per le
implementazioni TDI richiedono una larghezza di banda massima di 400 MB/s per
nodo HANA. Se, ad esempio, 10 nodi sono collegati in una SAN a un array VMAX, è
necessaria una larghezza di banda totale di 4000 MB/s. Presupponendo che una
porta front-end da 8 Gbps fornisca una larghezza di banda di circa 750 MB/s, per
supportare 10 nodi HANA (6 x 750 MB/s = 4500 MB/s) sono necessarie almeno sei
porte front-end a 8 Gpbs dedicate. Se si utilizzano porte front-end a 16 Gbps, sono
necessarie tre porte.
Sebbene questo requisito di larghezza di banda massima si presenti solo nel caso
improbabile che debba essere contemporaneamente soddisfatto in tutti i nodi, la
capacità degli storage array di supportare questo workload di picco costituisce uno
dei criteri della certificazione SAP HANA.
Questo requisito non interessa tuttavia solo la configurazione front-end dello
storage. In questo esempio con dieci nodi, per supportare la larghezza di banda
massima deve essere configurato anche il percorso completo attraverso la rete SAN.
In una SAN multi-hop, in cui più switch sono connessi tramite ISL (Inter Switch Link),
la larghezza di banda degli ISL deve supportare anche il requisito di larghezza di
banda massima.
Porte di storage
Quando si pianifica la connettività dello storage per i massimi livelli di prestazioni e
disponibilità, EMC consiglia di "lavorare in larghezza piuttosto che in profondità",
ovvero di collegare porte di storage di engine e director diversi,2anziché utilizzare
tutte le porte di un unico director. In questo modo, anche in caso di guasto di un
componente, lo storage può continuare a gestire le richieste di I/O dell'host.
2
Ogni engine VMAX dispone di due director ridondanti.
9
Una delle novità degli array VMAX3 e VMAX All-Flash è l'allocazione dinamica dei
core. Ogni director VMAX3 fornisce servizi come la connettività front-end, la
connettività back-end e la gestione dei dati. Per ciascuno di questi servizi in ogni
director è presente un set di core dedicato. I core vengono quindi raggruppati per
fornire le risorse di CPU che possono essere allocate in base alle necessità. Se, ad
esempio, le richieste di I/O dell'host giungono tramite una singola porta front-end sul
director, per soddisfare le richieste sarà disponibile l'intero pool front-end con tutti i
core CPU. Poiché per le richieste di I/O dirette ad altri director verranno utilizzati pool
di core separati, per ottenere i massimi livelli di prestazioni e disponibilità EMC
consiglia di collegare ciascun host a porte di director diversi prima di utilizzare porte
aggiuntive sullo stesso director.
SAP richiede che il workload HANA venga isolato dalle applicazioni non HANA. EMC
consiglia quindi di utilizzare porte front-end dedicate per HANA e di non condividerle
con applicazioni non HANA.
Porte HBA
Ogni porta HBA (Host Bus Adapter), o initiator, crea un percorso per le richieste di I/O
tra l'host e lo switch SAN che prosegue fino allo storage VMAX. È necessario utilizzare
due porte HBA, preferibilmente su due HBA separati. Due porte forniscono infatti più
connettività e consentono il multipathing nativo di Linux (DM-MPIO) per il
bilanciamento del carico e il failover su percorsi HBA.
Modelli di I/O di
HANA
I device HANA persistenti utilizzano diversi modelli di I/O. Per ulteriori informazioni,
fare riferimento al White paper relativo ai requisiti di storage di SAP HANA.
Volume di dati
L'accesso al volume di dati è essenzialmente casuale, con block di dimensioni
comprese tra 4 K e 64 M. I dati vengono scritti in modo asincrono con I/O paralleli nel
file system dei dati. Durante le normali operazioni, la maggior parte delle operazioni
di I/O dirette al file system dei dati è costituita da operazioni di scrittura e i dati
vengono letti dal file system solo durante il riavvio del database, il backup di HANA, il
failover automatico dell'host o un'operazione di caricamento o ricaricamento della
tabella di archivio colonne.
Volume di log
L'accesso al volume di log è essenzialmente sequenziale, con block di dimensioni
comprese tra 4 K e 1 M. HANA dedica un buffer da 1 M per il redo log in memoria.
Quando il buffer è pieno, il redo log viene scritto in modo sincrono nel volume di log.
Se viene eseguito il commit di una transazione di database prima che il buffer di log
sia pieno, nel file system viene scritto un block di piccole dimensioni. Poiché i dati
vengono scritti nel volume di log in modo sincrono, è importante garantire una bassa
latenza per le operazioni di I/O nello storage device, in particolare per i block più
piccoli da 4 K e 16 K.
Come per il volume di dati, durante le normali operazioni del database la maggior
parte delle richieste di I/O dirette al volume di log è costituita da operazioni di
10
scrittura e i dati vengono letti dal volume di log solo durante il riavvio del database, il
failover della high availability e il ripristino del database o il backup del log.
Le richieste di I/O di HANA possono essere ottimizzate per specifici ambienti di
storage. Il documento Ottimizzazione delle operazioni di I/O dei file dopo
l'installazione di HANA descrive procedure di ottimizzazione specifiche per gli array
VMAX.
Replica di storage
con Symmetrix
Remote Data
Facility
HANA supporta due tecnologie di replica: la replica dei volumi di storage tramite la
replica di storage e la replica basata su applicazioni tramite la replica di sistema
HANA.
EMC ha convalidato la replica di storage utilizzando il software SRDF (Symmetrix
Remote Data Facility), come descritto nelle seguenti guide alle soluzioni EMC:

Business Continuity e disaster recovery con EMC VMAX3 per
implementazioni di SAP HANA TDI

Best practice di Business Continuity per SAP HANA TDI con EMC Symmetrix
VMAX
Anche se è stata convalidata ed è supportata negli ambienti HANA, la replica di
storage sincrona tramite SRDF/S richiede un'attenta analisi dell'impatto sulla latenza
delle operazioni di I/O dei log HANA. A seconda della distanza e dell'infrastruttura di
rete tra i siti SRDF/S, la latenza delle operazioni di I/O può superare il valore di soglia
accettabile e determinare un significativo rallentamento dell'elaborazione delle
transazioni che, in alcuni casi, può scaturire in situazioni di blocco delle operazioni o
di memoria insufficiente.
Sebbene SAP non preveda un valore di soglia della latenza per le repliche di storage
relative a I/O di block di piccole dimensioni (4 K e 16 K), EMC consiglia di evitare che
queste latenze superino in modo significativo i KPI definiti da SAP per gli ambienti
non replicati.
Se nell'ambiente di un cliente l'utilizzo di SRDF/S determina una latenza superiore e
gli utenti riscontrano problemi alle prestazioni di HANA, EMC consiglia di passare alla
replica asincrona utilizzando il software SRDF/A, a condizione che sia accettabile
anche un obiettivo RPO (Recovery Point Objective) diverso da zero.
Scenari di
certificazione SAP
HANA
Dal momento in cui SAP ha introdotto il modello di implementazione TDI, vengono
utilizzati due diversi scenari per testare le prestazioni della persistenza di HANA (dati
e log) e verificare che lo storage array soddisfi i KPI SAP relativi a larghezza di banda
(MB/s) e latenza (microsecondi).
HANA-HWC-ES 1.0
Lo scenario di certificazione ES-HWC-HANA 1.0 è stato il primo scenario fornito da
SAP e utilizza lo strumento fstest sottostante per eseguire e convalidare operazioni di
I/O sui file system. Dal punto di vista del file system, fstest eseguiva operazioni di
I/O sequenziali e casuali, ma molte delle operazioni di I/O casuali sul file system
venivano considerate dallo storage array come operazioni di I/O sequenziali. Per
11
soddisfare gli indicatori KPI SAP era quindi necessario utilizzare un numero inferiore
di dischi.
Gli array VMAX 10K, 20K e 40K sono stati certificati utilizzando lo scenario HANAHWC-ES 1.0. I suggerimenti riportati in questa guida relativamente alla
configurazione e alla scalabilità di questi modelli si basano sullo scenario HANAHWC-ES 1.0. Quando si riconvalida un array VMAX 10K, 20K o 40K presso la sede di
un cliente, fare riferimento al documento SAP Note 1943937.
HANA-HWC-ES 1.1
Con SAP HANA 1.0 SP 10 e versioni successive, SAP ha introdotto un nuovo scenario
per la certificazione degli storage enterprise. La versione 1.1 utilizza lo strumento
fsperf sottostante per la convalida delle prestazioni del file system. Con lo strumento
fsperf, tuttavia, le operazioni di I/O casuali richiedono risorse aggiuntive e gli
indicatori KPI possono essere ottenuti solo con un maggior numero di dischi (HDD) o
dischi flash.
Gli array VMAX3, originariamente certificati con lo scenario ES-HWC-HANA 1.0, sono
stati ricertificati insieme agli array VMAX All-Flash anche con lo scenario HANA-HWCES 1.1. I suggerimenti riportati in questa guida relativamente alla configurazione e
alla scalabilità si basano sullo scenario HANA-HWC-ES 1.1. Quando si riconvalida un
array VMAX3 o VMAX All-Flash presso la sede di un cliente, fare riferimento al
documento SAP Note 1943937.
12
Principi di progettazione dello storage per SAP HANA su array VMAX (10K, 20K, 40K)
Principi di progettazione dello storage per SAP HANA su array VMAX
(10K, 20K, 40K)
I seguenti suggerimenti di configurazione si applicano ai sistemi di produzione HANA
implementati su enterprise storage array VMAX 10K, 20K e 40K. I sistemi di
produzione HANA presenti negli ambienti TDI devono soddisfare i requisiti di
prestazioni (KPI) SAP; è inoltre necessario applicare i requisiti di configurazione
speciali descritti di seguito.
Scalabilità
Tabella 1 fornisce linee guida per stimare il numero iniziale di host di produzione
HANA che è possibile collegare, sulla base dei test sulle prestazioni eseguiti su un
engine VMAX 10K utilizzando lo strumento SAP hwcct (per lo scenario ES-HWC-HANA
1.0).
Nota: la scalabilità di modelli superiori ed engine aggiuntivi è stata determinata
estrapolando i risultati dei test sul VMAX 10K e utilizzando le caratteristiche di prestazioni
dei modelli più elevati.
Il numero effettivo degli host HANA che è possibile collegare a un array VMAX
nell'ambiente di un cliente può essere superiore o inferiore al numero elencato nella
Tabella 1 in base al workload effettivo. EMC consiglia di utilizzare lo strumento HANA
hwcct dello scenario ES-HWC-HANA 1.0 negli ambienti dei clienti per convalidare le
prestazioni di HANA e determinare il numero massimo possibile di host HANA in un
determinato storage array.
Tabella 1. Scalabilità degli array VMAX 10K, 20K e 40K
Modelli
VMAX
Numero di engine disponibili
Numero di worker host HANA
10K
1
12
2
18
3
24
4
30
1
12
2
20
3
28
4
36
5
44
6
52
7
60
8
68
20K
13
Requisiti di
director/porte FA
Modelli
VMAX
Numero di engine disponibili
40K
1
12
2
22
3
32
4
42
5
52
6
62
7
72
8
82
Oltre alle informazioni fornite nella sezione Porte di storage, sono previsti requisiti
speciali quando si collegano nodi HANA alle porte front-end del director (porte FA) di
un array VMAX 10K, 20K o 40K.
Su un director VMAX, due porte FA condividono un core CPU dedicato. A scopo
illustrativo, si ipotizzi che FA-1E:0 e FA-1E:1 condividano lo stesso core. Per ottenere
le massime prestazioni di I/O per le implementazioni di HANA, utilizzare solo una
porta FA per ogni core di CPU sul modulo di I/O. Ad esempio, è possibile utilizzare la
porta FA-1E:0 e lasciare la porta FA-1E:1 inutilizzata. Non si deve utilizzare la porta
adiacente in caso di applicazioni non HANA. Figura 2 e la Figura 3 illustrano la vista
posteriore di engine VMAX con moduli di I/O FC a 4 porte (8 Gbps) per la connettività
dell'host. Le quattro porte sono denominate 0, 1, 2 e 3. EMC consiglia di utilizzare le
porte di I/O contrassegnate con una casella gialla (porta 0 e porta 2) per la
connettività di HANA poiché la porta 0 e la porta 1 condividono un core di CPU mentre
le porte 2 e 3 condividono un altro core di CPU. Lasciare le porte adiacenti
inutilizzate.
Figura 2.
14
Vista posteriore dell'engine VMAX 10K
Figura 3.
Considerazioni sul
provisioning
virtuale
Vista posteriore degli engine VMAX 20K e 40K
Gli array VMAX 10K, 20K e 40K utilizzano EMC Virtual ProvisioningTM per fornire
capacità di storage a un'applicazione. La capacità viene allocata mediante device
TDAT (Thin Data Devices) e fornita in thin pool in base alla tecnologia dei dischi e al
tipo di RAID. I thin device (TDEV) sono device accessibili dall'host collegati a thin
pool e distribuiti in modo nativo sul pool per fornire i massimi livelli di prestazioni.
Fully Automated Storage Tiering for Virtual Pools (FAST VP)
FAST sposta i dati presenti in un array VMAX da uno storage tier a un altro per
ottimizzare le prestazioni e il risparmio economico. I dati più utilizzati vengono
archiviati sullo storage tier più veloce (e più costoso), mentre i dati meno utilizzati
vengono archiviati sullo storage tier più lento (e meno costoso). Negli ambienti
HANA, è possibile che questi algoritmi di spostamento dei dati non generino i
risultati previsti. HANA modifica i dati nella memoria dei server e, quando nel file
system viene scritto un punto di salvataggio, è possibile che venga scritto in una
posizione diversa nel file system anche se i dati non sono stati modificati nella
memoria.
Pertanto, l'utilizzo della tecnologia FAST VP non fornisce alcun vantaggio in termini di
persistenza di HANA e un singolo storage tier basato su disco rigido da 10K o 15K
costituisce la soluzione migliore negli array VMAX 10K, 20K e 40K. L'utilizzo di SSD
per lo storage tier di HANA è facoltativo e non è necessario per soddisfare i requisiti
di prestazioni relativi allo scenario di certificazione HANA-HWC-ES 1.0.
Dischi e gruppi di dischi
In un array VMAX, i gruppi di dischi contengono dischi della stessa tecnologia, ovvero
FC, SAS o SSD. I gruppi di dischi sono preconfigurati con l'array oppure vengono
creati quando si aggiungono unità all'array per aumentare la capacità disponibile. La
creazione di gruppi di dischi richiede il coinvolgimento di EMC Customer Service.
Per isolare ancora meglio il workload HANA dalle applicazioni non HANA su un array
condiviso, valutare la possibilità di predisporre un gruppo di dischi dedicato per
HANA. Ponderare attentamente la scelta tra le prestazioni e l'isolamento del
workload ed evitare la creazione di gruppi di dischi dedicati per HANA con meno di
40 dischi (HDD).
15
Ogni nodo worker HANA richiede almeno dieci dischi (da 10.000 rpm o 15.000 rpm)
per soddisfare i requisiti di IOPS previsti dallo scenario di certificazione SAP HANAHWC-ES 1.0. Per i massimi livelli di prestazioni delle configurazioni HANA, il numero
di dischi in un gruppo deve essere divisibile per 8 (se si utilizzano dischi HDD).
Considerazioni sui RAID
Per fornire le migliori prestazioni di scrittura per la persistenza di HANA, EMC
consiglia di utilizzare una configurazione RAID1 con mirroring per i device TDAT su
dischi da 10.000 rpm o 15.000 rpm. Se si utilizzano unità SSD, è consigliata una
configurazione RAID 5 3+1.
Thin pool
EMC consiglia la creazione di un thin pool per tutti i volumi di dati HANA e di un
secondo thin pool per i volumi di log HANA presenti nell'array VMAX. Tuttavia, se in
ambienti HANA di piccole dimensioni è disponibile un numero limitato di dischi, è
possibile migliorare le prestazioni utilizzando un unico thin pool per entrambi i tipi di
volumi. I thin pool sono costituiti da device TDAT. Il numero e le dimensioni dei
device TDAT in un thin pool dipende dai requisiti di capacità di SAP HANA e devono
essere configurati in base alle best practice di configurazione degli array VMAX.
Quando si creano device TDAT, verificare che ad ogni disco vengano assegnati otto
hyper volume (divisioni). Modificare le dimensioni dei device TDAT in base alla
capacità disco utilizzabile. Accertarsi inoltre che i device TDAT vengano creati su tutti
i dischi disponibili.
Esempio:

Sono disponibili 64 dischi 512 hyper volume (64 x 8 = 512)

Un TDAT RAID1 ha due hyper volume  crea 256 TDAT (512 / 2 = 256)

Le dimensioni dei TDAT devono corrispondere alla capacità utilizzabile di un
disco diviso per 8
Creare thin pool per i file di log e di dati utilizzando il numero di TDAT che
soddisfa i requisiti di capacità
Metavolumi per dati e log
Ciascun worker host HANA richiede un volume di dati e un volume di log per i file
system permanenti. Le dimensioni dei volumi dipendono dai Requisiti di capacità
HANA.
Visualizzazione
masking
Creare un metavolume TDEV per i dati HANA utilizzando 32 membri.

Creare un metavolume TDEV per il log HANA utilizzando 8 membri.
VMAX utilizza le visualizzazioni masking per assegnare storage a un host. EMC
consiglia di creare un'unica visualizzazione masking per ogni host HANA (scale-up) o
cluster HANA (scale-out). Una visualizzazione masking è costituita dagli elementi
seguenti:

16

Initiator group
Principi di progettazione dello storage per SAP HANA su array VMAX3 e VMAX All Flash (100K, 200K, 400K, 250F/FX,
450F/FX, 850F/FX)

Port group

Storage group
Initiator group
L'initiator group contiene gli initiator (WWN) degli HBA (Host Bus Adaptor) sull'host
HANA. Collegare ciascun host HANA all'array VMAX con almeno due porte HBA per
garantire la necessaria ridondanza.
Port group
Il port group contiene le porte front-end del director a cui sono collegati gli host
HANA. Fare riferimento alle sezioni Porte di storage e Requisiti di director/porte FA
per determinare il numero di porte necessarie per l'installazione di HANA.
Storage group
Un cluster scale-out HANA ricorre al concetto di "shared-nothing" per la persistenza
del database, in cui ciascun worker host HANA utilizza la propria coppia di volumi di
log e di dati e dispone di un accesso esclusivo a questi volumi durante le normali
operazioni. In caso di guasto di un worker host HANA, la persistenza di HANA relativa
all'host danneggiato viene utilizzata su un host di standby. A questo scopo, tuttavia,
è necessario che tutti i volumi persistenti siano visibili a tutti gli host HANA poiché
qualsiasi host può diventare un worker host o un host di standby.
Lo storage group VMAX di un database HANA deve contenere tutti i device persistenti
del cluster di database. Il nome del server HANA e l'API dello storage connector HANA
gestiscono il mounting della persistenza e l'isolamento delle operazioni di I/O in
modo da garantire che un solo nodo per volta abbia accesso a una determinata
coppia di volumi di log e di dati.
Installazione di SAP HANA su array VMAX 10K, 20K, 40K
Per istruzioni, fare riferimento alle sezioni Preparazione dei nodi HANA e Installazione
del cluster scale-out HANA. Queste sezioni descrivono l'installazione di HANA su un
array VMAX All-Flash, ma possono essere utilizzate anche come riferimento per
l'installazione del database su VMAX 10K, 20K e 40K.
Principi di progettazione dello storage per SAP HANA su array VMAX3 e
VMAX All Flash (100K, 200K, 400K, 250F/FX, 450F/FX, 850F/FX)
I suggerimenti di configurazione illustrati in questa sezione si applicano ai sistemi
HANA implementati su enterprise storage array VMAX3 e VMAX All Flash. I sistemi di
produzione HANA presenti negli ambienti TDI devono soddisfare i SAP KPI e i
seguenti requisiti di configurazione.
Scalabilità
Basata sui nostri test sulle prestazioni di un singolo engine VMAX 100K e un VMAX
450F con unico V-Brick tramite lo strumento SAP hwcct (per la certificazione HANAHWC-ES 1.1), la Tabella 2 offre le linee guida per stimare il numero iniziale di host di
produzione HANA che è possibile collegare.
17
450F/FX, 850F/FX)
Nota: la scalabilità di modelli superiori e V-Brick ed engine aggiuntivi è stata determinata
estrapolando i risultati dei test sui VMAX 100K e 450F e utilizzando le caratteristiche di
prestazioni dei modelli più elevati.
Il numero effettivo di host HANA che è possibile collegare a un array VMAX
nell'ambiente di un cliente può essere superiore o inferiore al numero di host HANA
elencato nella Tabella 2 in base al workload effettivo. Utilizzare lo strumento HANA
hwcct dello scenario HANA-HWC-ES 1.1 negli ambienti dei clienti per convalidare le
prestazioni di HANA e definire il numero massimo possibile di host HANA su un
determinato storage array.
Tabella 2.
Scalabilità degli array VMAX3 e VMAX All-Flash
Modello VMAX3
100K e 250F/FX
200K e 450F/FX
400K e 850F/FX
Provisioning
basato sui Service
Level Objective
18
Engine o V-Brick
1
12
2
20
1
16
2
28
3
40
4
52
1
20
2
32
3
44
4
56
5
68
6
80
7
92
8
104
FAST in VMAX3
Con VMAX3, la tecnologia FAST (Fully Automated Storage Tiering) è stata ottimizzata
in modo da includere sia lo storage provisioning intelligente sia la gestione delle
prestazioni utilizzando gli SLO (Service Level Objective). Gli SLO automatizzano
l'allocazione e la distribuzione dei dati delle applicazioni nel pool di dati e nello
storage tier corretti senza alcun intervento manuale. Mentre con la tecnologia FAST
VP sugli array VMAX 10K, 20K e 40K lo spostamento dei dati veniva attivato in base
all'obsolescenza dei dati, gli SLO degli array VMAX3 sono associati alla latenza di I/O
media prevista per le operazioni di lettura e di scrittura. Sia il provisioning iniziale sia
le prestazioni dinamiche delle applicazioni, quindi, vengono misurati
450F/FX, 850F/FX)
automaticamente e gestiti in base alla conformità agli storage tier e agli obiettivi di
prestazioni. FAST controlla l'attività dello storage ogni 10 minuti e, se necessario,
sposta i dati con granularità delle sub-LUN FAST, pari a 5,25 MB (42 extent di 128
KB). Gli SLO possono essere modificati dinamicamente (aumentati o diminuiti) in
qualsiasi momento e FAST monitorizza e modifica costantemente la posizione dei
dati con granularità delle sub-LUN tra gli storage tier disponibili per soddisfare gli
obiettivi di prestazioni specificati. Tutte queste operazioni vengono eseguite
automaticamente all'interno dello storage array VMAX3, senza dover implementare
una complessa strategia ILM3 per le applicazioni o utilizzare risorse dell'host per la
migrazione dei dati per esigenze di prestazioni.
Un pool di risorse di storage (SRP) è una raccolta di pool di dati che offre la
tecnologia FAST con un dominio per la gestione della capacità e delle prestazioni. Per
impostazione predefinita, viene preconfigurato un unico SPR predefinito. Gli
spostamenti di dati eseguiti dalla tecnologia FAST avvengono entro i confini del pool
SRP. HANA non richiede un SRP separato e può coesistere con applicazioni non HANA
nello stesso SRP a condizione che vengano utilizzati SLO appropriati, come descritto
nella sezione Best practice per SLO e tipi di workload per HANA.
SRP è una raccolta di pool di dati che offre la tecnologia FAST con un dominio per la
gestione della capacità e delle prestazioni. Per impostazione predefinita, viene
preconfigurato un unico SPR predefinito. Gli spostamenti di dati eseguiti dalla
tecnologia FAST avvengono entro i confini del pool SRP.
Tipi di SLO e
workload
Sono disponibili cinque SLO, che variano in base agli obiettivi previsti in termini di
tempo di risposta medio come elencato nella Tabella 3. È disponibile un ulteriore
SLO ottimizzato a cui non è associato alcun obiettivo esplicito in termini di tempo di
risposta.
Tabella 3.
Informazioni sugli SLO
SLO
Tempo di risposta medio
previsto
Diamond
0,8-2,3 ms
Platinum
3-4,4 ms
Gold
5-6,5 ms
Silver
8-9,5 ms
Bronze
14-15,5 ms
Ottimizzato
(predefinito)
N/A
3
Informazioni Lifecycle Management (ILM) si riferisce a una strategia di gestione dei dati delle applicazioni basata su policy. Prevede
complesse procedure di analisi, mapping e monitoraggio dei dati.
19
450F/FX, 850F/FX)
Se si seleziona uno SLO diverso da uno SLO ottimizzato, è possibile qualificarlo
ulteriormente in base al tipo di workload: OLTP (Online Transaction Processing) o DSS
(Decision-Support System). Il workload OLTP è incentrato sull'ottimizzazione delle
prestazioni per I/O di piccoli block, mentre il workload DSS è incentrato
sull'ottimizzazione delle prestazioni per I/O di grandi block. Il tipo di workload può
anche specificare se sono previsti overhead per operazioni di replica (locale o
remota). I qualificatori del tipo di workload relativi agli overhead di replica sono
OLTP_Rep e DSS_Rep, dove "Rep" sta per "replicati". Tabella 4 elenca i tipi di
workload disponibili.
Tabella 4.
Tipi di workload per VMAX3
Workload
Descrizione
OLTP
Workload di I/O di piccoli block
OLTP con replica
Workload di I/O di piccoli block con replica locale o remota
DSS
Workload di I/O di grandi block
DSS con replica
Workload di I/O di grandi block con replica locale o remota
Per le installazioni di HANA sono consigliate le seguenti configurazioni di SLO. Tenere
Best practice per
presente che gli array VMAX All-Flash offrono solo il livello di servizio Diamond.
SLO e tipi di
workload per HANA
Persistenza di HANA (dati e log) per le installazioni di HANA di produzione
Per le installazioni di produzione HANA, EMC consiglia di utilizzare lo SLO Diamond
per la persistenza di HANA (i volumi di dati e log). Sebbene HANA utilizzi block di
varie dimensioni, si consiglia di specificare il tipo di workload OLTP. In questo modo,
l'array VMAX3 tenta di mantenere la latenza sotto la soglia di 1 ms, che costituisce un
requisito SAP per i block di piccole dimensioni (4 K e 16 K) sul volume di log.
L'utilizzo dello SLO Diamond con device all-flash consente di usufruire dei seguenti
vantaggi nelle installazioni di HANA di produzione:

Tempi di avvio di HANA ridotti quando i dati vengono letti dal volume di dati
in memoria

Tempi ridotti per il failover automatico di host HANA nelle implementazioni
scale-out quando un nodo di standby acquisisce i dati da un nodo worker
guasto

Riduzione dei tempi di backup di HANA quando il processo di backup
richiede la lettura dei dati dal volume di dati

Latenze inferiori al millisecondo per i block di piccole dimensioni sul volume
di log
Persistenza di HANA (dati e log) per le installazioni di HANA non di produzione
Sebbene i KPI SAP non valgano per le installazioni di HANA non di produzione,
queste installazioni costituiscono comunque componenti critici negli ambienti SAP.
20
450F/FX, 850F/FX)
EMC consiglia quindi di utilizzare lo SLO Gold per tutte le installazioni di HANA non di
produzione.
Installazione di HANA (/hana/shared/)
Uno SLO Bronze è sufficiente quando si utilizza eNAS in un array VMAX3 per fornire la
share NFS per il file system di installazione di HANA
Uno SLO Bronze può essere sufficiente anche per l'immagine di avvio del sistema
operativo.
Che cosa succede se un array VMAX3 esistente non supporta lo SLO Diamond?
Quando un nuovo array VMAX3 viene configurato per un ambiente HANA, vengono
automaticamente aggiunte unità SSD con la capacità necessaria per abilitare lo SLO
Diamond per le installazioni di HANA di produzione. Alcuni clienti, tuttavia,
potrebbero voler utilizzare per il database HANA array VMAX3 esistenti senza unità
SSD. In questi ambienti, è possibile che ne risentano i tempi di risposta e le
prestazioni di HANA e che si verifichi un rallentamento delle operazioni di riavvio,
backup o ricaricamento delle tabelle. Ma non solo: si riduce anche il numero di nodi
di HANA di produzione che è possibile collegare all'array (come illustrato nella
Tabella 1). In questi casi, è possibile utilizzare il più alto SLO disponibile per HANA.
Considerazioni sugli SLO in caso di workload concorrenti che generano interferenze
In ambienti altamente consolidati, HANA compete per le risorse di storage con altri
database e applicazioni. Se vengono specificati gli SLO e i tipi di workload, FAST può
fornire a ciascuno di essi le prestazioni appropriate. Utilizzando diversi SLO per ogni
applicazione (o gruppo di applicazioni), risulta molto semplice gestire un ambiente
consolidato di questo tipo e modificare gli SLO in base all'evoluzione delle esigenze
aziendali. La sezione seguente descrive altri modi per controllare le prestazioni in un
ambiente consolidato.
Limiti di I/O dell'host e multi-tenancy
La funzionalità QoS (Qualità del Servizio) che limita le operazioni di I/O dell'host era
già stata introdotta in array VMAX di precedente generazione. In VMAX3 continua a
offrire ai clienti la possibilità di inserire specifici limiti di IOPS o larghezza di banda,
indipendentemente dallo SLO assegnato al gruppo. Assegnando un limite di IOPS
dell'host a uno storage group di un workload HANA concorrente con bassi requisiti di
prestazioni, ad esempio, è possibile garantire che un picco di richieste di I/O non
influisca sul workload HANA e sulle prestazioni.
21
Installazione e configurazione dello storage di un cluster scale-out HANA in un array VMAX All-Flash: Esempio
Installazione e configurazione dello storage di un cluster scale-out HANA
in un array VMAX All-Flash: Esempio
In questa sezione viene descritto come:

Creare e configurare lo storage persistente (dati e log) su un array VMAX AllFlash per un cluster scale-out HANA con tre nodi worker e un nodo di
standby (3+1)

Preparare gli host HANA

Installare il cluster HANA utilizzando lo strumento da riga di comando per la
gestione del ciclo di vita SAP hdblcm
Per configurare lo storage su array VMAX3 100K, 200K e 400K è possibile seguire la
stessa procedura, rispetto alla quale è necessario anche selezionare il livello di
servizio in cui è stato creato lo storage group. Gli array VMAX3 consentono infatti di
scegliere tra più livelli di servizio per le installazioni di HANA: selezionare il livello di
servizio Diamond per le installazioni di produzione e il livello di servizio Gold per le
installazioni non di produzione.
Configurazione
dell'array VMAX
All-Flash
È stata utilizzata l'interfaccia grafica (GUI) di Unisphere for VMAX per configurare tutti
gli storage device, gli storage group, i port group, gli host group e la visualizzazione
masking per lo scale-out cluster di HANA. Seguire i seguenti passaggi:
1.
Accedere a Unisphere e passare al dashboard Storage Group, come illustrato
nella Figura 4.
Figura 4.
2.
22
Dashboard Storage Group
Fare clic sul riquadro Total per visualizzare gli storage group esistenti come
illustrato nella Figura 5.
Figura 5.
3.
Storage group esistenti
Fare clic su Create SG per creare un nuovo storage group per il cluster HANA,
come illustrato nella Figura 6.
Figura 6.
Creazione di un nuovo storage group
Per il cluster 3+1 HANA sono stati necessari tre volumi di dati (ciascuno da 1,5 TB) e
tre volumi di log (ciascuno da 512 GB). È stato quindi creato uno storage group a
cascata con un gruppo di primo livello (HANA_ABC), un sottogruppo per tutti i volumi
di dati (HANA_ABC_D) e un secondo sottogruppo per tutti i volumi di log
(HANA_ABC_L). In seguito, sono stati specificati il numero e le dimensioni dei volumi
da creare. Sugli array VMAX All-Flash, è disponibile solo il livello di servizio Diamond.
Sugli array VMAX3 Hybrid (100K, 200K, 400K), è opportuno scegliere il livello di
servizio Diamond per le istanze HANA di produzione e Gold per le istanze HANA non
di produzione.
4.
Fare clic sulla freccia verso il basso accanto a Add to Job List e quindi su Run
Now. Viene creato il nuovo storage group a cascata, come illustrato nella
Figura 6.
23
Figura 7.
5.
Selezionare lo storage group HANA_ABC_D e fare clic su View Details per
visualizzare le informazioni sui volumi creati come illustrato nella Figura 8.
Figura 8.
6.
Volumi creati
Fare clic su Volumes – 3 nell'area RELATED OBJECTS per visualizzare l'elenco
dei volumi di dati. Figura 9 è illustrato un esempio.
Figura 9.
24
Storage group a cascata
Elenco dei volumi di dati
7.
Osservare il valore WWN del volume.
8.
Ripetere questo passaggio per tutti i volumi di dati e di log. Lo storage
connector di HANA (fcClient) utilizza il valore WWN per identificare una
storage LUN. Il valore WWN è specificato nel file HANA global.ini.
Impostare alias per gli initiator (nomi host e HBA)
Selezionare Host > Initiators. Fare clic con il pulsante destro del mouse sull'initiator,
selezionare Rename Alias e specificare un alias per ogni host HANA e porta HBA
(initiator) come illustrato nella Figura 10. Eseguire questa operazione una sola volta
per ogni initiator, anche se un initiator può essere connesso a più porte di storage.
Figura 10.
Impostazione di alias per gli initiator
In questo esempio, ogni HBA è connesso a una porta di ciascun director (1D e 2D) del
V-Brick presente nell'array VMAX All-Flash. Prendere nota delle porte a cui si
connettono gli initiator.
Se non si conoscono i valori WWN degli initiator dei nodi HANA, è possibile eseguire
il seguente comando Linux sul nodo per trovare queste informazioni:
# systool -c fc_host -v | grep -i port_name
port_name = "0x10000090fa53fd1c"
port_name = "0x10000090fa53fd1d"
Creazione di un host group
1.
Selezionare Host > Create Host Group. Immettere un nome nel formato
HANA_ABC, selezionare gli host appartenenti al cluster HANA e fare clic su
Add, come illustrato nella Figura 10.
25
Figura 11.
2.
Creazione di host group
Fare clic sulla freccia verso il basso accanto a Add to Job List e selezionare
Run Now. Viene creato l'host group come illustrato nella Figura 12.
Figura 12.
Host group creato
Creare un port group
1.
26
Selezionare Hosts > Port Groups > Create Port Group. Immettere un nome, ad
esempio HANA_ABC), come illustrato nella Figura 13 e contrassegnare le
porte a cui sono connessi gli initiator tenendo premuto il tasto CTRL.
Figura 13.
2.
Fare clic su OK. È possibile che venga visualizzato il messaggio di avviso
illustrato nella Figura 14.
Figura 14.
3.
Creazione di un port group
Messaggio di avviso relativo al port group
Fare clic su OK per confermare che nel port group sono presenti più porte
dello stesso director: in questo esempio, FA-1D:28, FA1D:30 e FA-2D:28, FA2D:30.
Per un singolo host, è consigliata una relazione 1:1 tra una porta HBA dell'host e una
porta front-end dello storage. In questo caso, tuttavia, è stato creato un port group
per un cluster HANA ed erano quindi richiesti un throughput e una larghezza di banda
per più host.
Creare una visualizzazione masking
Una visualizzazione masking di VMAX combina lo storage group, il port group e l'host
group e consente l'accesso ai volumi di storage dai nodi HANA.
1.
Selezionare Hosts > Masking View > Create Masking View.
27
2.
Immettere un nome per la visualizzazione masking (HANA_ABC) e
selezionare l'host group, il port group e lo storage group creati nei passaggi
precedenti come illustrato nella Figura 15.
Figura 15.
Creazione di una visualizzazione masking
Fare clic su OK. Viene creata la visualizzazione masking come illustrato nella Figura
16.
Figura 16.
Visualizzazione masking
I nodi HANA hanno ora accesso ai volumi di storage.
È stato creato un sistema scale-out HANA con tre nodi worker e un nodo di standby
(3+1). In un cluster HANA con quattro nodi, ogni nodo deve poter accedere a ogni
device HANA. Durante l'avvio di HANA, il nameserver HANA, insieme allo storage
connector di HANA fcClient, si occupa del mouting4 dei volumi sul nodo HANA
appropriato e dell'isolamento di I/O. A questo scopo, tuttavia, è necessaria una
corretta preparazione dei nodi HANA e del file HANA global.ini prima di procedere
4
Quando si utilizza lo storage connector di HANA fcClient, non deve essere eseguito il mounting automatico del device tramite
/etc/fstab
28
all'installazione effettiva di HANA. Questi passaggi sono descritti nella sezione
seguente.
Preparazione dei
nodi HANA
Questo esempio presuppone che siano state precedentemente completate le
operazioni di installazione e configurazione di base sui nodi HANA, come indicato di
seguito:

Il sistema operativo è stato installato e correttamente configurato in base ai
suggerimenti SAP (in questo esempio è stato utilizzato SUSE Linux 12 per
applicazioni SAP)

È stato creato un file system HANA condiviso (/hana/shared/) su un
sistema NAS, ad esempio, su un array VMAX3 o VMAX All-Flash con
funzionalità eNAS e ne è stato eseguito il mounting su tutti i nodi HANA.

Sui nodi HANA è stato installato il multipathing nativo di Linux (DM-MPIO)

Tutte le impostazioni di rete e i requisiti di larghezza di banda per le
comunicazioni tra i nodi sono state configurate in base ai requisiti SAP

Le chiavi SSH sono state scambiate tra tutti i nodi HANA

La sincronizzazione dell'ora di sistema è stata configurata utilizzando un
server NTP

Il file ISO DVD per l'installazione di HANA è stato scaricato dal sito web di
SAP e reso disponibile su un file system condiviso
Nota: SAP HANA può essere installato esclusivamente su server hardware certificati.
L'installazione deve essere eseguita da un esperto HANA certificato.
Le sezioni seguenti illustrano i passaggi necessari per:

La configurazione dello storage sui nodi HANA

La preparazione del file global.ini di HANA

L'installazione di un'istanza scale-out HANA con lo strumento da riga di
comando per la gestione del ciclo di vita HANA hdblcm utilizzando i volumi
di storage creati nei passaggi precedenti.
Multipathing nativo di Linux (DM-MPIO)
Utilizzare le voci seguenti nel file /etc/multipath.conf:
defaults {
user_friendly_names
no
}
devices {
device {
vendor
"EMC"
product
"SYMMETRIX"
getuid_callout
"/lib/udev/scsi_id -g -u -d /dev/%n"
features
"0"
hardware_handler
"0"
path_selector
"round-robin 0"
path_grouping_policy "multibus"
rr_weight
"uniform"
no_path_retry
"fail"
rr_min_io
"100"
29
path_checker
"directio"
prio
"const"
prio_args
""
flush_on_last_del yes
fast_io_fail_tmo off
dev_loss_tmo
120
}
}
Riavviare il multipathing dopo aver modificato il file /etc/multipath.conf utilizzando il
comando seguente:
# service multipath restart
Inizializzazione della persistenza di HANA
La persistenza di HANA deve essere visibile da ogni nodo del cluster HANA.
Utilizzare il comando rescan-scsi-bus.sh o riavviare ciascun nodo.
Per verificare che i volumi siano visibili, utilizzare i seguenti comandi su uno dei nodi:
Elencare tutti i volumi di dati da 1,5 TB:
# multipath -ll | grep -B1 -A5 1.5T
360000970000197000112533030303338 dm-6 EMC,SYMMETRIX
size=1.5T features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=1 status=active
|- 0:0:0:11 sdm 8:192
active ready running
|- 0:0:4:11 sdcs 70:0
|- 1:0:7:11 sdlk 68:288 active ready running
`- 1:0:0:11 sdfs 130:224 active ready running
-360000970000197000112533030303337 dm-5 EMC,SYMMETRIX
|- 0:0:0:10 sdl 8:176
|- 0:0:4:10 sdcr 69:240 active ready running
|- 1:0:7:10 sdlj 68:272 active ready running
`- 1:0:0:10 sdfr 130:208 active ready running
-360000970000197000112533030303336 dm-18 EMC,SYMMETRIX
|- 0:0:0:9 sdk 8:160
|- 0:0:4:9 sdcq 69:224 active ready running
|- 1:0:7:9 sdli 68:256 active ready running
`- 1:0:0:9 sdfq 130:192 active ready running
Elencare tutti i volumi di log da 512 GB:
# multipath -ll | grep -B1 -A5 512G
360000970000197000112533030303339 dm-4 EMC,SYMMETRIX
size=512G features='1 queue_if_no_path' hwhandler='0' wp=rw
|- 0:0:0:12 sdn 8:208
|- 0:0:4:12 sdct 70:16
|- 1:0:7:12 sdll 68:304 active ready running
`- 1:0:0:12 sdft 130:240 active ready running
360000970000196701016533030313841 dm-47 EMC,SYMMETRIX
30
|- 0:0:1:15 sdaf 65:240 active ready running
|- 0:0:5:15 sddi 71:0
|- 1:0:5:15 sdjj 8:464
`- 1:0:2:15 sdgu 132:160 active ready running
360000970000197000112533030303342 dm-7 EMC,SYMMETRIX
|- 0:0:0:13 sdo 8:224
|- 0:0:4:13 sdcu 70:32
|- 1:0:7:13 sdlm 68:320 active ready running
`- 1:0:0:13 sdfu 131:0
L'identificatore univoco del device multipath, preceduto dal numero 3, deve
corrispondere al valore WWN dei volumi creati in Unisphere.
Inizializzare quindi i device e creare il file system XFS di Linux su ciascuno dei device
utilizzando il seguente comando di esempio:
# mkfs.xfs /dev/mapper/360000970000197000112533030303341
Dopo aver creato tutti i file system, è possibile installare il cluster scale-out HANA.
Installazione del
cluster scale-out
HANA
Prima di eseguire lo script di installazione, preparare i due file di configurazione
seguenti:

Un file global.ini con una sezione di storage in cui sono descritte le partizioni
dello storage HANA, le opzioni di mounting e lo storage connector da
utilizzare

Un file di parametri di installazione utilizzato dallo script da riga di comando
hdblcm con parametri di installazione personalizzati
Preparare il file global.ini
L'installazione utilizza il file global.ini per descrivere le partizioni dello storage HANA
e lo storage connector da utilizzare. Tutte le piattaforme di storage EMC con
certificazione HANA utilizzano lo storage connector fcClient, che fa parte della
distribuzione software SAP.
Verificare che nel file global.ini sia riportato il contenuto seguente:
[storage]
ha_provider = hdb_ha.fcClient
partition_*_*__prtype = 5
partition_*_data__mountoptions = -o inode64
partition_*_log__mountoptions = -o inode64,nobarrier
partition_1_data__wwid = 360000970000197000112533030303336
partition_1_log__wwid = 360000970000197000112533030303339
31
Assicurarsi che le voci di partizione corrispondano all'identificatore di device univoco
visualizzato. A questo scopo, utilizzare il comando multipath –ll preceduto dal
numero 3.
Posizionare il file global.ini (nome obbligatorio) in una directory del file system
/hana/shared/, ad esempio /hana/shared/ABC_cfg. Installazioni scale-out di HANA
di grandi dimensioni richiedono voci di partizione aggiuntive.
Preparare il file dei parametri di installazione
Con SAP HANA SPS 07 è stato introdotto uno strumento di gestione del ciclo di vita
dei database SAP HANA che permette di installare tutti i componenti
contemporaneamente, automatizzando l'installazione e garantendo ai clienti
maggiore flessibilità. Nell'esempio seguente viene utilizzata l'interfaccia a riga di
comando hdblcm per installare il cluster scale-out HANA 3+1.
1.
Nel file system condiviso, passare alla directory HDB_LCM_LINUX_X86_64 in
cui è stato estratto il file ISO DVD per l'installazione di HANA utilizzando il
comando seguente:
# cd /<installation media>/DATA_UNITS/HDB_LCM_LINUX_X86_64
2.
Creare un template di file di parametri di installazione utilizzando il comando
hdblcm seguente:
# ./hdblcm --action=install -dump_configfile_template=ABC_install.cfg
3.
Dopo aver creato il template, modificare i seguenti parametri del file per
soddisfare i requisiti dell'ambiente in uso:
# Directory root to search for components
component_root=/SAPShare/software/SAP_HANA_SPS11_IM/51050506
/
# Components ( Valid values: all | client | es | ets |
lcapps | server | smartda | streaming | rdsync | xs | studio
| afl | pos | sal | sca | sop | trd | udf )
components=server,client
# Installation Path ( Default: /hana/shared )
sapmnt=/hana/shared
# Local Host Name ( Default: server06 )
hostname=C240-08W
# Directory containing a storage configuration
storage_cfg=/hana/shared/ABC_cfg
Nota: il parametro sopra riportato fa riferimento alla directory in cui è stato
posizionato il file global.ini personalizzato.
# SAP HANA System ID
sid=ABC
# Instance Number
32
number=00
# System Administrator User ID
userid=1001
# ID of User Group (sapsys)
groupid=79
# Action to be performed ( Default: exit; Valid values:
install | update | extract_components )
action=install
# Additional Hosts
addhosts=C240-03E:storage_partition=2:role=worker,C24002C:storage_partition=3:role=worker,C240-2M2:role=standby
Nota: il parametro sopra riportato descrive gli host aggiuntivi e i rispettivi ruoli
nell'installazione scale-out.
4.
Nel file di parametri è possibile specificare una password per l'utente root,
una per l'utente host agent SAP (sapadm), una per l'utente System
Administrator (<sid>adm) e una per l'utente del database (SYSTEM). È
possibile anche utilizzare password crittografate. Per maggiori informazioni,
fare riferimento a SAP HANA Installation and Upgrade Guide. La procedura
hdblcm informa l'utente in caso di password o parametri mancanti.
5.
Esaminare l'intero file template e specificare eventuali parametri aggiuntivi
necessari per il proprio ambiente.
Installare il cluster scale-out SAP HANA utilizzando l'interfaccia a riga di comando
hdblcm
Dopo aver creato il file global.ini e i file dei parametri di installazione e averli
personalizzati in base alle proprie esigenze, avviare l'installazione utilizzando il
comando seguente:
# ./hdblcm --action=install –-configfile=ABC_Install.cfg
SAP HANA Lifecycle Management - SAP HANA 1.00.110.00.1447753075
***************************************************************
Scanning Software Locations...
Detected components:
SAP HANA Database (1.00.110.00.1447753075) in
/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/HDB_SERVE
R_LINUX_X86_64/server
SAP HANA AFL (incl.PAL,BFL,OFL,HIE) (1.00.110.00.1447766426)
in
/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/HDB_AFL_L
INUX_X86_64/packages
SAP TRD AFL FOR HANA (1.00.110.00.1447766426) in
/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/HDB_TRD_A
FL_LINUX_X86_64/packages
33
SAP HANA Database Client (1.00.110.00.1447753075) in
/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/HDB_CLIEN
T_LINUX_X86_64/client
SAP HANA Studio (2.2.8.000000) in
/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/HDB_STUDI
O_LINUX_X86_64/studio
SAP HANA Smart Data Access (1.00.6.001.0) in
/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/SAP_HANA_
SDA_10_LINUX_X86_64/packages
SAP HANA XS Advanced Runtime (1.0.9.258635) in
/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/XSA_RT_10
_LINUX_X86_64/packages
XS Monitoring 1 (1.001.1) in
/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/XSA_CONTE
NT_10/XSAC_MONITORING-1.1.1.zip
XS Services 1 (1.001.0) in
NT_10/XSAC_SERVICES-1.1.0.zip
SAP Hana Demo Model for XS Advanced 1.0 (1.001.4) in
NT_10/XSAC_SHINE-1.1.4.zip
Collecting information from host 'c240-03e'...
Collecting information from host 'c240-02c'...
Collecting information from host 'c240-2m2'...
Information collected from host 'c240-03e'.
Information collected from host 'c240-2m2'.
Information collected from host 'c240-02c'.
Restrict maximum memory allocation? [n]: n
Enter Certificate Host Name For Host 'c240-08w'
Enter Certificate Host Name For Host 'c240-03e'
Enter Certificate Host Name For Host 'c240-02c'
Enter Certificate Host Name For Host 'c240-2m2'
Enter System Administrator (abcadm) Password:
Confirm System Administrator (abcadm) Password:
Enter Database User (SYSTEM) Password:
Confirm Database User (SYSTEM) Password:
[c240-08w]:
[c240-03e]:
[c240-02c]:
[c240-2m2]:
Summary before execution:
=========================
SAP HANA Components Installation
Installation Parameters
Remote Execution: ssh
Installation Path: /hana/shared
Local Host Name: c240-08w
Root User Name: root
Directory containing a storage configuration:
/hana/shared/ABC_cfg
SAP HANA System ID: ABC
Instance Number: 09
Database Mode: single_container
System Usage: custom
Location of Data Volumes: /hana/data/ABC
Location of Log Volumes: /hana/log/ABC
Certificate Host Names: c240-08w -> c240-08w, c240-2m2 ->
c240-2m2, c240-03e -> c240-03e, c240-02c -> c240-02c
System Administrator Home Directory: /usr/sap/ABC/home
34
System Administrator Login Shell: /bin/sh
System Administrator User ID: 1010
ID of User Group (sapsys): 79
Software Components
SAP HANA Database
Install version 1.00.110.00.1447753075
Location:
/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/HDB_SERVE
R_LINUX_X86_64/server
SAP HANA AFL (incl.PAL,BFL,OFL,HIE)
Do not install
SAP TRD AFL FOR HANA
Do not install
SAP HANA Database Client
Do not install
SAP HANA Studio
Do not install
SAP HANA Smart Data Access
Do not install
SAP HANA XS Advanced Runtime
Do not install
Additional Hosts
c240-2m2
Role: Database Standby (standby)
Storage Partition: N/A
c240-03e
Role: Database Worker (worker)
Storage Partition: 2
c240-02c
Role: Database Worker (worker)
Storage Partition: 3
Do you want to continue? (y/n): y
[….]
Sistema SAP HANA installato
È possibile inviare commenti e suggerimenti a SAP utilizzando
questo modulo: https://c24008w:1129/lmsl/HDBLCM/ABC/feedback/feedback.html
File di registro scritto in "/var/tmp/hdb_ABC_hdblcm_install_201604-17_17.09.22/hdblcm.log" sull'host "C240-08W".
Ottimizzazione
delle operazioni di
I/O dei file dopo
l'installazione di
HANA
Il livello base di HANA fornisce due interfacce di I/O:

Simple File  Utilizzata per piccole e semplici richieste di I/O su file di
configurazione, tracce e cosìvia. Si avvale di leggeri wrapper indipendenti
dalla piattaforma per chiamate di sistema.

FileFactory&File  Utilizzata per grandi e complessi flussi di richieste di I/O
su volumi di dati e di log e per operazioni di backup e ripristino. Si avvale di
operazioni di I/O sincrone e asincrone.
35
È possibile configurare il livello di I/O dei file HANA con specifici parametri di
configurazione per ottimizzare le richieste di I/O dei file per uno storage array e un
file system specifici (il file system XFS di Linux viene utilizzato in tutte le storage LUN
di EMC per la persistenza di HANA).
1.
2.
Dopo aver installato la persistenza di HANA nelle LUN di VMAX, impostare i
seguenti parametri del livello di I/O del file per un'elaborazione ottimale delle
richieste di I/O:

max_parallel_io_requests=256

async_read_submit=on

async_write_submit_blocks=all
Quando l'installazione iniziale di HANA è completata, impostare i parametri
utilizzando il comando hdbparam come <sid>adm nella shell di Linux:
#
#
#
#
#
su - <sid>adm
hdbparam –p
# lists current parameter setting
hdbparam –-paramset fileio.max_parallel_io_requests=256
hdbparam –-paramset fileio.async_read_submit=on
hdbparam –-paramset fileio.async_write_submit_blocks=all
Nota: le istruzioni sopra riportate per l'ottimizzazione dei parametri di I/O dei file sono
basate su SAP HANA 1.0 SPS 11. Nelle future versioni di SAP HANA è possibile che questi
parametri possano essere impostati nei file di configurazione. Per informazioni aggiornate,
fare riferimento alla documentazione più recente su SAP HANA.
36
Conclusioni
Conclusioni
Riepilogo
L'utilizzo di SAP HANA in implementazioni TDI con enterprise storage array EMC
VMAX, VMAX3 e VMAX All-Flash offre numerosi vantaggi, tra cui la riduzione dei costi
hardware e operativi, la riduzione dei rischi, il miglioramento della disponibilità e
delle prestazioni e l'aumento della flessibilità dei vendor di componenti hardware.
Tutti gli array VMAX sono certificati da SAP e possono essere utilizzati per le seguenti
installazioni di HANA: produzione e non produzione, sistemi con singolo nodo (scaleup) e sistemi scale-out.
Rilievi
Durante i test con HANA su array VMAX, è stato osservato che:

Lo scenario di certificazione SAP HANA-HWC-ES 1.0 richiede un numero
inferiore di risorse del disco, come descritto nella sezione Principi di
progettazione dello storage per SAP HANA su array VMAX (10K, 20K, 40K).

Lo scenario di certificazione SAP HANA-HWC-ES 1.1 prevede requisiti più
elevati relativamente alla configurazione del disco.

Le installazioni di HANA di produzione su sistemi VMAX3 e VMAX All-Flash
richiedono unità SSD per la persistenza di HANA.

L'utilizzo di SSD per la persistenza di HANA offre vantaggi significativi, ad
esempio:

Possibilità di eseguire la configurazione iniziale dei dischi e degli array
in base alla capacità, senza dover prendere in considerazione il numero
di spindle

Riduzione dei tempi di avvio di HANA e di failover automatico degli host

Riduzione dei tempi di backup di HANA
37
Riferimenti
Riferimenti
Documentazione
EMC
Documentazione
su SAP HANA
Nei documenti riportati di seguito, disponibili sul sito web italy.emc.com o sul sito
web del Supporto Online EMC, vengono fornite informazioni aggiuntive pertinenti.
L'accesso a questi documenti dipende dalle credenziali di login di cui si dispone. Se
non si riesce ad accedere a un documento, contattare la sede locale o un
responsabile EMC.

Guida alla famiglia di prodotti Symmetrix VMAX (Symmetrix VMAX 10K (SN
xxx987xxxx), VMAX 20K, VMAX 40K)

Famiglia VMAX3 con sistema operativo HYPERMAX: VMAX 100K, VMAX
200K, VMAX 400K - Guida al prodotto

EMC VMAX All Flash Family VMAX 250F, 450F, 850F

Guida al prodotto VMAX All-Flash: 450F, VMAX 450FX, VMAX 850F, VMAX
850FX con sistema operativo HYPERMAX

Unisphere for VMAX 8.0.3 - Set di documentazione

Business Continuity e disaster recovery con EMC VMAX3 per
implementazioni di SAP HANA TDI

Best practice di Business Continuity per SAP HANA TDI con EMC Symmetrix
VMAX

Guida alla soluzione SAP HANA nell'ambiente virtualizzato VMware con
storage EMC

Guida alla connettività host di EMC per Linux
La documentazione riportata di seguito, disponibile sul sito web di SAP, fornisce
informazioni aggiuntive pertinenti:

SAP HANA Master Guide

SAP HANA Server Installation and Update Guide

SAP HANA Studio Installation and Update Guide

SAP HANA Technical Operations Manual

SAP HANA Administration Guide
Risorse web

SAP HANA Storage Requirements

SAP HANA Appliance

SAP HANA One

SAP HANA Enterprise Cloud

SAP HANA Tailored Data Center Integration
Nota: la seguente documentazione richiede un nome utente e una password SAP.

38
SAP Note 1943937 - Hardware Configuration Check Tool - Central Note

best practice per la configurazione dello storage

Transcript

Documenti analoghi

Ciao, sono un`amica di Hana Brady una bambina normale che

VENERDI` 21 MAGGIO ORE 20.30

dagli studenti un film sulla shoah

L`esperienza Natuzzi

SAP HANA 2016

fumiko ishioka

Hana Brady è una povera ragazza che ha subito un maltrattamento

QUI - Anfi