Tipi di Archiviazione di Azure per carichi di lavoro SAP

Azure offre numerosi tipi di archiviazione che differiscono notevolmente in funzionalità, velocità effettiva, latenza e prezzi. Alcuni tipi di archiviazione non sono utilizzabili o sono utilizzabili in modo limitato per gli scenari SAP. Altri tipi di archiviazione di Azure, invece, sono adatti o ottimizzati per scenari di carico di lavoro SAP specifici. In particolare per SAP HANA, alcuni tipi di archiviazione di Azure sono stati certificati per l'utilizzo con SAP HANA. In questo documento vengono illustrati i diversi tipi di archiviazione e vengono descritte le funzionalità e l'usabilità con carichi di lavoro SAP e componenti SAP.

Osservazioni sulle unità usate in questo articolo. I fornitori di cloud pubblico sono passati a utilizzare GiB (Gibibyte) o TiB (Tebibyte come unità di misura, invece di Gigabyte o Terabyte. Di conseguenza, tutta la documentazione e la valutazione di Azure usano tali unità. In tutto il documento si fa riferimento esclusivamente alle unità di misura MiB, GiB e TiB. Potrebbe essere necessario pianificare con MB, GB e TB. Pertanto, è necessario tenere conto di alcune piccole differenze nei calcoli se è necessario ridimensionare per una velocità effettiva di 400 MiB/sec, anziché di 250 MiB/sec.

Resilienza di Archiviazione di Microsoft Azure

Archiviazione di Microsoft Azure di HDD Standard, SSD Standard, Archiviazione Premium di Azure, SSD Premium v2 e Archiviazione su disco Ultra mantengono il disco rigido virtuale di base (con sistema operativo) e i dischi di dati collegati alle macchine virtuali o i dischi rigidi virtuali in tre copie su tre nodi di archiviazione diversi. Il failover in un'altra replica e il seeding di una nuova replica in caso di errore del nodo di archiviazione sono trasparenti. A causa di questa ridondanza, NON è necessario usare alcun tipo di livello di ridondanza dell'archiviazione su più dischi di Azure. Questo approccio è denominato archiviazione con ridondanza locale (LRS). L'archiviazione con ridondanza locale è l'impostazione predefinita per questi tipi di archiviazione in Azure. Azure NetApp Files offre una ridondanza sufficiente per ottenere gli stessi contratti di servizio (contratti di servizio) di altre risorse di archiviazione native di Azure.

Esistono diversi metodi di ridondanza, tutti descritti nell'articolo Replica di Archiviazione di Azure che si applicano ad alcuni dei diversi tipi di archiviazione offerti da Azure.

Tenere inoltre presente che i diversi tipi di archiviazione di Azure influenzano i contratti di servizio di disponibilità delle singole macchine virtuali rilasciati nel Contratto di servizio per le macchine virtuali.

Dischi gestiti di Azure

I dischi gestiti sono un tipo di risorsa in Azure Resource Manager, utilizzabili al posto dei dischi rigidi virtuali archiviati negli account di Archiviazione di Azure. I dischi gestiti vengono allineati automaticamente al [availability set][virtual-machines-manage-availability] della macchina virtuale a cui sono collegati. Con questo allineamento si verifica un miglioramento della disponibilità della macchina virtuale e dei servizi in esecuzione nella macchina virtuale. Per altre informazioni, leggere l’articolo introduttivo.

Scenari di archiviazione con carichi di lavoro SAP

L'archiviazione persistente è necessaria nel carico di lavoro SAP in vari componenti dello stack distribuito in Azure. Questi scenari si presentano almeno come segue:

• Permanente il disco rigido virtuale di base della macchina virtuale che contiene il sistema operativo e altri software installati nel disco. Questo disco/disco rigido virtuale è la radice della macchina virtuale. Tutte le modifiche apportate, devono essere mantenute. In questo modo, la volta successiva che si arresta e si riavvia la macchina virtuale, tutte le modifiche apportate in precedenza sono ancora valide. In particolare, nei casi in cui la macchina virtuale viene distribuita da Azure in un altro host rispetto a quello su cui era in esecuzione originariamente
• Dischi dati permanenti. Questi dischi sono dischi rigidi virtuali collegati per archiviare i dati dell'applicazione. Questi dati dell'applicazione possono essere file di dati e di log/ripristino di un database, file di backup o installazioni software. Indica qualsiasi disco oltre il disco rigido virtuale di base che contiene il sistema operativo
• Condivisioni file o dischi condivisi che contengono la directory di trasporto globale per NetWeaver o S/4HANA. Il contenuto di tali condivisioni viene utilizzato dal software in esecuzione in più macchine virtuali o viene usato per creare scenari di cluster di failover a disponibilità elevata
• Directory /sapmnt o condivisioni di file comuni per processi EDI (Electronic Data Interchange) o simili. Il contenuto di tali condivisioni viene utilizzato dal software in esecuzione in più macchine virtuali o viene usato per creare scenari di cluster di failover a disponibilità elevata

Nelle sezioni successive vengono illustrati i diversi tipi di archiviazione di Azure e la relativa usabilità per i quattro scenari di carico di lavoro SAP. Una categorizzazione generale su come usare i diversi tipi di archiviazione di Azure è documentata nell'articolo Quali tipi di disco sono disponibili in Azure?. Gli elementi consigliati per l'uso dei diversi tipi di archiviazione di Azure per il carico di lavoro SAP non saranno molto diverse.

Per le restrizioni di supporto per i tipi di archiviazione di Azure per SAP NetWeaver/livello applicazione di S/4HANA, leggere la nota di supporto SAP 2015553. Per i tipi di archiviazione di Azure con certificazione HANA e supportati, leggere l'articolo Configurazioni di archiviazione delle macchine virtuali di Azure con SAP HANA.

Le sezioni che descrivono i diversi tipi di archiviazione di Azure offrono informazioni più approfondite sulle restrizioni e sulle possibilità di utilizzo dell'archiviazione supportata da SAP.

Opzioni di archiviazione quando si usa la replica DBMS

Le architetture di riferimento prevedono l'utilizzo di funzionalità del sistema di gestione di database come Gruppi di disponibilità Always On di SQL Server, Replica di sistema HANA, Disponibilità elevata e ripristino di emergenza Db2 o Oracle Data Guard. Nel caso in cui si usino queste tecnologie tra due o più macchine virtuali di Azure, i tipi di archiviazione scelti per ognuna delle macchine virtuali devono essere uguali. Indica che la configurazione di archiviazione tra nodo attivo e nodo di replica nella configurazione a disponibilità elevata del sistema DBMS deve essere la stessa.

Elementi consigliati per l'archiviazione per scenari di archiviazione SAP

Prima di esaminare i dettagli, verranno presentati il riepilogo e gli elementi consigliati già all'inizio del documento. Mentre i dettagli per i tipi specifici di Archiviazione di Azure seguono questa sezione del documento. Quando si riassumono gli elementi consigliati di archiviazione per gli scenari di archiviazione SAP in una tabella, l'aspetto è simile al seguente:

¹ Con l'utilizzo di acceleratore di scrittura di Azure per le famiglie di macchine virtuali M/Mv2 per i volumi di log/rollforward

Caratteristiche che è possibile prevedere dall'elenco dei diversi tipi di archiviazione, ad esempio:

¹ Con l'utilizzo di acceleratore di scrittura di Azure per le famiglie di macchine virtuali M/Mv2 per i volumi di log/rollforward

² La creazione di pool di capacità di Azure NetApp Files diversi non garantisce la distribuzione di pool di capacità in unità di archiviazione diverse

³ (Incrementale) Snapshot di un'unità SSD Premium v2 o di un disco Ultra non possono essere usati immediatamente dopo la creazione. Prima di poter creare un disco dallo snapshot, è necessario completare la copia in background

Archiviazione Premium di Azure

L'archiviazione SSD Premium di Azure è stata introdotta con l'obiettivo di offrire i vantaggi seguenti:

• Bassa latenza di I/O
• Contratti di servizio per operazioni di I/O al secondo e velocità effettiva
• Minore variabilità della latenza di I/O

Questo tipo di archiviazione è destinato ai carichi di lavoro DBMS, al traffico di archiviazione che richiede una latenza di pochi millisecondi e ai contratti di servizio in operazioni di I/O al secondo e velocità effettiva. I costi di Archiviazione Premium di Azure non sono basati sui volumi di dati effettivi archiviati in tali dischi, ma sulla categoria di dimensioni di un disco, indipendentemente dalla quantità di dati archiviati nel disco. È anche possibile creare dischi in Archiviazione Premium privi di mapping diretto alle categorie di dimensioni illustrate nell'articolo SSD Premium. Le conclusioni di questo articolo sono:

• Le risorse di archiviazione sono organizzate in intervalli. Ad esempio, i dischi con capacità compresa tra 513 GiB e 1.024 GiB condividono le stesse funzionalità e gli stessi costi mensili
• Le operazioni di I/O al secondo per GiB non vengono monitorate in modo lineare tra le categorie di dimensioni. I dischi più piccoli inferiori a 32 GiB hanno velocità di I/O al secondo più elevate per GiB. Per i dischi con capacità compresa tra 32 GiB e 1.024 GiB, la velocità delle operazioni di I/O al secondo per GiB oscilla tra 4-5 operazioni di I/O al secondo per GiB. Per dischi di dimensioni maggiori fino a 32.767 GiB, la velocità di I/O al secondo per GiB è inferiore a 1
• La velocità effettiva di I/O per questa risorsa di archiviazione non è lineare con le dimensioni della categoria del disco. Per i dischi più piccoli, ad esempio della categoria compresa tra 65 GiB e 128 GiB di capacità, la velocità effettiva è di circa 780 KB per GiB. Mentre per i dischi di grandi dimensioni estremi come un disco GiB di 32.767, la velocità effettiva è di circa 28 KB per GiB
• I contratti di servizio di operazioni di I/O al secondo e velocità effettiva non possono essere modificati senza modificare la capacità del disco

La matrice di funzionalità per il carico di lavoro SAP è simile alla seguente:

Archiviazione Premium di Azure non soddisfa gli indicatori KPI di latenza di archiviazione SAP HANA con i tipi di memorizzazione nella cache comuni offerti con Archiviazione Premium di Azure. Per soddisfare gli indicatori KPI di latenza di archiviazione per le scritture di log SAP HANA, è necessario usare la memorizzazione nella cache dell'acceleratore di scrittura di Azure descritto nell'articolo Abilitare l'acceleratore di scrittura. L'acceleratore di scrittura di Azure offre vantaggi a tutti gli altri sistemi DBMS per le scritture di log di transazione e le scritture di log di rollforward. È quindi consigliabile usarlo in tutte le distribuzioni DBMS SAP. Per SAP HANA, l'uso dell'acceleratore di scrittura di Azure per /hana/log con archiviazione Premium di Azure è obbligatorio.

Riepilogo: archiviazione Premium di Azure è uno dei tipi di archiviazione di Azure consigliati per il carico di lavoro SAP. Questa raccomandazione è applicabile sia ai sistemi di produzione che a quelli non di produzione. Archiviazione Premium di Azure è adatta a gestire i carichi di lavoro dei database. L'utilizzo dell'acceleratore di scrittura di Azure consentirà di migliorare sostanzialmente la latenza di scrittura rispetto ai dischi Premium di Azure. Tuttavia, per i sistemi DBMS con velocità effettiva e operazioni di I/O al secondo elevate, è necessario effettuare l'overprovisioning della capacità di archiviazione. In alternativa, è necessario usare funzionalità come Spazi di archiviazione di Windows o i gestori di volumi logici in Linux per creare set di striping che offrono la capacità desiderata da un lato. Ma anche le operazioni di I/O al secondo o la velocità effettiva con la migliore efficienza dei costi.

Funzionalità di Azure per Archiviazione Premium in modalità burst

Per i dischi di archiviazione Premium di Azure più piccoli o uguali a 512 GiB di capacità, viene offerta la funzionalità burst. Il modo esatto in cui funziona il bursting del disco è descritto nell'articolo Bursting del disco. Quando si legge l'articolo, si comprende il concetto di accumulare operazioni di I/O al secondo e velocità effettiva nei momenti in cui il carico di lavoro di I/O è inferiore alle operazioni di I/O nominale e alla velocità effettiva dei dischi (per informazioni dettagliate sulla velocità effettiva nominale, vedere Prezzi dei dischi gestiti). Si accumulerà il delta di IOPS e la velocità effettiva tra l'utilizzo attuale e i valori nominali del disco. I burst sono limitati a un massimo di 30 minuti.

I casi ideali in cui è possibile pianificare la funzionalità burst riguardano i volumi o i dischi che contengono file di dati per il differente sistema di gestione di database. Il carico di lavoro di I/O previsto rispetto a tali volumi, in particolare con sistemi di piccole e medie dimensioni dovrebbe essere simile al seguente:

• Carico di lavoro di lettura da basso a moderato perché i dati sono idealmente memorizzati nella cache in memoria. In alternativa, con SAP HANA il carico di lavoro deve essere completamente in memoria
• Picchi di scrittura attivati da checkpoint di database o punti di salvataggio emessi con regolarità
• Carico di lavoro di backup che legge in flusso continuo nei casi in cui i backup non vengono eseguiti tramite snapshot di archiviazione
• Per SAP HANA, caricamento dei dati in memoria dopo il riavvio di un'istanza

In particolare nei sistemi DBMS più piccoli, in cui il carico di lavoro gestisce solo poche centinaia di transazioni al secondo, tale funzionalità burst può essere utile anche per i dischi o i volumi che archiviano la transazione o il log di rollforward. Il carico di lavoro previsto per un disco o un volume di questo tipo è simile al seguente:

• Scritture regolari nel disco che dipendono dal carico di lavoro e dalla natura del carico di lavoro, perché è probabile che ogni commit emesso dall'applicazione attivi un'operazione di I/O
• Carico di lavoro più elevato in termini di velocità effettiva per i casi di attività operative, come la creazione o la ricostruzione degli indici
• Picchi di lettura durante l'esecuzione di copie di backup dei log delle transazioni o dei log di ripristino

SSD Premium di Azure v2

L'archiviazione SSD Premium v2 di Azure è una nuova versione dell'archiviazione Premium introdotta con l'obiettivo di fornire:

• Latenza I/O di sotto-millisecondo per dimensioni di I/O di lettura e scrittura inferiori
• Contratti di servizio per operazioni di I/O al secondo e velocità effettiva
• Pagare la capacità in base ai GB di cui è stato effettuato il provisioning
• Fornire un set predefinito di operazioni di I/O al secondo e velocità effettiva di archiviazione per disco
• Offrire la possibilità di aggiungere altre operazioni di I/O al secondo e velocità effettiva a ogni disco e pagare separatamente per queste risorse aggiuntive di cui è stato effettuato il provisioning
• Superare la certificazione SAP HANA senza l'ausilio di altre funzionalità, come l'acceleratore di scrittura di Azure o altre cache

Questo tipo di archiviazione è destinato ai carichi di lavoro DBMS, al traffico di archiviazione che richiede una latenza di sotto-millisecondo e ai contratti di servizio in operazioni di I/O al secondo e velocità effettiva. I dischi SSD Premium v2 vengono distribuiti con un set predefinito di 3.000 operazioni di I/O al secondo e una velocità effettiva di 125 MBps. E la possibilità di aggiungere altre operazioni di I/O al secondo e velocità effettiva ai singoli dischi. I prezzi dell'archiviazione sono strutturati in modo che l'aggiunta di una maggiore velocità effettiva o di maggiori operazioni di I/O al secondo non influisca in modo significativo sul prezzo. Tuttavia, si lascia che sia l'utente a decidere come sarà la propria configurazione di archiviazione per Premium SSD v2. Per un avvio di base, leggere Configurazioni di archiviazione SSD Premium v2 delle macchine virtuali di Azure con SAP HANA.

Per le aree effettive, è disponibile questo nuovo tipo di archiviazione a blocchi; per le restrizioni effettive leggere il documento SSD Premium v2.

La matrice di funzionalità per il carico di lavoro SAP è simile alla seguente:

¹ (Incrementale) Snapshot di un'unità SSD Premium v2 o di un disco Ultra non possono essere usati immediatamente dopo la creazione. Prima di poter creare un disco dallo snapshot, è necessario completare la copia in background

Invece dell'archiviazione Premium di Azure, l'unità SSD Premium di Azure v2 soddisfa gli indicatori KPI di latenza di archiviazione SAP HANA. Di conseguenza, NON è necessario usare la memorizzazione nella cache dell'acceleratore di scrittura di Azure come descritto nell'articolo Abilitare l'acceleratore di scrittura.

Riepilogo: SSD Premium di Azure v2 è l'archiviazione a blocchi con il miglior rapporto prezzo/prestazioni per i carichi di lavoro SAP. L'unità SSD Premium di Azure v2 è adatta per gestire i carichi di lavoro del database. La latenza di sottomillisecondo è l'archiviazione ideale per carichi di lavoro DBMS impegnativi. Anche se si tratta di un tipo di archiviazione più recente rilasciato a novembre 2022. Pertanto, potrebbero esserci ancora alcune limitazioni che scompariranno nei prossimi mesi.

Disco Ultra di Azure

I dischi Ultra di Azure offrono una velocità effettiva elevata, un numero elevato di operazioni di I/O al secondo e archiviazione su disco con bassa latenza coerente per le macchine virtuali IaaS di Azure. Alcuni vantaggi delle unità Dischi Ultra includono la possibilità di modificare dinamicamente le operazioni di I/O al secondo e la velocità effettiva del disco, in base ai carichi di lavoro, senza dover riavviare le macchine virtuali (VM). I dischi Ultra sono adatti per i carichi di lavoro a elevato utilizzo di dati, come il carico di lavoro DBMS SAP. I dischi Ultra possono essere usati solo come dischi di dati e non possono essere usati come dischi rigidi virtuali di base che archiviano il sistema operativo. È consigliabile usare l'archiviazione Premium di Azure come disco rigido virtuale di base.

Quando si crea un disco Ultra, è possibile definire tre dimensioni:

• La capacità del disco. Gli intervalli sono compresi tra 4 GiB e 65.536 GiB
• Operazioni di I/O al secondo di cui è stato effettuato il provisioning per il disco. Valori massimi diversi si applicano alla capacità del disco. Per altre informazioni, leggere l'articolo Disco Ultra
• Larghezza di banda di archiviazione con provisioning. La larghezza di banda massima diversa si applica in base alla capacità del disco. Per altre informazioni, leggere l'articolo Disco Ultra

Il costo di un singolo disco è determinato dalle tre dimensioni che è possibile definire separatamente per i dischi specifici.

La matrice di funzionalità per il carico di lavoro SAP è simile alla seguente:

¹ (Incrementale) Snapshot di un'unità SSD Premium v2 o di un disco Ultra non possono essere usati immediatamente dopo la creazione. Prima di poter creare un disco dallo snapshot, è necessario completare la copia in background

Riepilogo: dischi Ultra di Azure è una risorsa di archiviazione adatta con bassa latenza di sotto-millisecondo per tutti i tipi di carico di lavoro SAP. Al momento, il disco Ultra può essere usato solo in combinazione con macchine virtuali distribuite tramite zone di disponibilità (distribuzione di zona) A differenza di tutte le altre risorse di archiviazione, il disco Ultra non può essere usato per il disco rigido virtuale di base. Il disco Ultra è ideale per i casi in cui il carico di lavoro di I/O varia molto e si vuole adattare la velocità effettiva di archiviazione o le operazioni di I/O al secondo distribuite ai modelli di carico di lavoro di archiviazione anziché ridimensionarle per l'utilizzo massimo della larghezza di banda e delle operazioni di I/O al secondo.

Azure NetApp Files

Azure NetApp Files è un servizio di archiviazione file nativo di Azure, di prima parte, di classe enterprise e ad alte prestazioni, certificato per l'uso con SAP HANA. Il sistema offre Volumi come servizio per i quali si creano account NetApp, pool di capacità e volumi. Con Azure NetApp Files, è possibile selezionare i livelli di servizio e prestazioni e gestire la protezione dei dati per creare e dirigere condivisioni di file ad alte prestazioni, a disponibilità elevata e scalabili, usando gli stessi protocolli e strumenti con cui si ha familiarità e su cui si fa affidamento in locale.

I tipi di carico di lavoro SAP seguenti sono supportati nei volumi di Azure NetApp Files:

• Carico di lavoro DBMS SAP
• Condivisione SAPMNT
• Directory di trasporto globale

Azure NetApp Files è disponibile in tre livelli di servizio, ognuno con le proprie specifiche di velocità effettiva e prezzi. Quale sia il più adatto dipende dalle dimensioni della distribuzione. Le raccomandazioni personalizzate per il dimensionamento sono disponibili in Stima del costo totale di proprietà di SAP in Azure NetApp Files.

Per informazioni sui livelli di servizio, vedere Livelli di servizio per Azure NetApp Files.

Distribuzione di volumi

Per ottenere risultati ottimali, usare il Gruppo di volumi dell'applicazione per SAP HANA per distribuire i volumi. Il gruppo di volumi dell'applicazione dispone i volumi in posizioni ottimali nell'infrastruttura di Azure usando regole di affinità e anti-affinità per ridurre i conflitti e consentire la velocità effettiva migliore e la latenza più bassa.

Azure NetApp Files è supportato per diversi scenari di carico di lavoro SAP:

• Distribuzioni SAP HANA che usano le condivisioni NFS per i volumi /hana/data, /hana/log e /hana/shared come documentato nelle configurazioni di archiviazione delle macchine virtuali di Azure SAP HANA.
• Fornitura di condivisioni SMB o NFS per la directory di trasporto globale di SAP
• La condivisione sapmnt in scenari a disponibilità elevata, come documentato in:
  • Disponibilità elevata per SAP NetWeaver in macchine virtuali di Azure su Windows con Azure NetApp Files (SMB) per applicazioni SAP
  • Disponibilità elevata per SAP NetWeaver su macchine virtuali di Azure su SUSE Linux Enterprise Server con Azure NetApp Files per applicazioni SAP
  • Disponibilità elevata delle macchine virtuali di Azure per SAP NetWeaver su Red Hat Enterprise Linux con Azure NetApp Files per applicazioni SAP
• IBM Db2 in una macchina virtuale di Azure basata su Suse o Red Hat Linux
• Distribuzioni SAP in Oracle nel sistema operativo guest Oracle Linux usando dNFS per i volumi di dati e log di rollforward Oracle. Per altri dettagli, vedere l'articolo Distribuzione Oracle DBMS di macchine virtuali di Azure per il carico di lavoro SAP
• SAP nell'ambiente del servizio app in Suse o nel sistema operativo guest Red Hat Linux
• SAP in MAXDB nel sistema operativo guest Suse o Red Hat Linux
• SAP in Microsoft SQL Server con volumi SMB

Disaccoppiamento della velocità effettiva dalle dimensioni del volume

L'archiviazione per le applicazioni di database ha in genere requisiti di velocità effettiva che non vengono ridimensionati in modo lineare con le dimensioni dei volumi, i volumi di log sono relativamente piccoli, ma richiedono livelli elevati di velocità effettiva.

Azure NetApp Files consente di allocare la velocità effettiva del volume in modo indipendente dalle dimensioni del volume quando si usa un pool di capacità di tipo QoS manuale.

Ecco un esempio:

• Un volume per i file di database richiede una velocità effettiva di 500 MiB/s e una capacità di 39 TiB
• Un volume per i file di log richiede una velocità effettiva di 2000 MiB/s e una capacità di 1 TiB

È possibile creare un pool di capacità QoS manuale per questo scenario e allocare velocità effettiva indipendentemente dalle dimensioni del volume. La capacità totale necessaria è 40 TiB e il budget della velocità effettiva totale è 2500 MiB/s. Un pool di capacità nel livello di servizio Premium (64 MiB/s per TiB allocato) soddisfa i requisiti di prestazioni e capacità (40 MiB * 64 iB/s/TiB = 2560 MiB).

Per ottenere il requisito di velocità effettiva, il ridimensionamento delle prestazioni lineari richiederebbe un notevole overprovisioning del volume di log. Per raggiungere la velocità effettiva di 2000 MiB/s per il volume di log, è necessario distribuire un pool di capacità nel livello Ultra (128 MiB/s per TiB allocato) di 16 TiB, con conseguente overprovisioning e quindi uno spreco di capacità di 15 TiB.

Usare la Calcolatrice delle prestazioni di Azure NetApp Files per ottenere una stima per lo scenario.

La matrice di funzionalità per il carico di lavoro SAP in Azure NetApp Files è simile alla seguente:

Altre funzionalità integrate dell'archiviazione di Azure NetApp Files:

• Capacità di eseguire snapshot coerenti con l'applicazione del volume usando AzAcSnap
• Clonazione di volumi da snapshot di Azure NetApp Files per test e sviluppo
• Ripristino di volumi da snapshot (snap-revert) per ripristini rapidi da danneggiamenti ed errori

Il motivo per cui si ricorre a questo tipo di allineamento della zona di disponibilità è la riduzione della superficie di rischio, in quanto le condivisioni NFS si trovano nella stessa zona di disponibilità delle macchine virtuali dell'applicazione.

• Distribuire i volumi di Azure NetApp Files per la distribuzione di SAP HANA tramite il gruppo di volumi dell'applicazione per SAP HANA. Il vantaggio del Gruppo di volumi dell'applicazione consiste nel fatto che i volumi di dati vengono distribuiti su più endpoint di archiviazione, riducendo così i conflitti di rete e migliorando le prestazioni.

Riepilogo: Azure NetApp Files è una soluzione di archiviazione a bassa latenza certificata per SAP HANA. Questo servizio offre volumi ricavati da uno o più pool di capacità. I pool di capacità sono disponibili in tre livelli di servizio che definiscono la capacità totale e la velocità effettiva allocate. È possibile ridimensionare i volumi e regolare la velocità effettiva allocata senza interruzione del servizio, in modo da soddisfare i requisiti in continua evoluzione e controllare i costi. Il servizio offre la possibilità di replicare i volumi in altre aree o zone per scopi di ripristino di emergenza e continuità aziendale.

File Premium di Azure

File Premium di Azure è una risorsa di archiviazione condivisa che offre SMB e NFS a un prezzo moderato e una latenza sufficiente per gestire le condivisioni del livello di applicazione SAP. In primo piano, File Premium di Azure offre la replica a zona sincrona delle condivisioni con un automatismo che, in caso di errore di una replica, consente a un'altra replica in un'altra zona di assumere il controllo. A differenza di Azure NetApp Files, non esistono livelli di prestazioni. Non è inoltre necessario un pool di capacità. L'addebito si basa sulla capacità effettiva di provisioning delle diverse condivisioni. File Premium di Azure non è stato testato come risorsa di archiviazione DBMS per il carico di lavoro SAP. Tuttavia, lo scenario di utilizzo del carico di lavoro SAP è incentrato su tutti i tipi di condivisioni SMB e NFS usati nel livello dell'applicazione SAP. File Premium di Azure è adatto anche per l'utilizzo con /hana/shared.

Scenari SAP supportati in File Premium di Azure, sono:

• Fornitura di condivisioni SMB o NFS per la directory di trasporto globale di SAP
• Utilizzo come condivisione per le interfacce con i sistemi SAP e i processi EDI
• La condivisione sapmnt in scenari a disponibilità elevata, come documentato in:
  • Disponibilità elevata per SAP NetWeaver su macchine virtuali di Azure su SUSE Linux Enterprise Server con NFS nei File di Azure
  • Disponibilità elevata per SAP NetWeaver su macchine virtuali di Azure su Red Hat Enterprise Linux con NFS nei File di Azure
  • Disponibilità elevata per SAP NetWeaver in macchine virtuali di Azure su Windows con SMB Premium di File di Azure per applicazioni SAP
  • Disponibilità elevata per il sistema scale-out di SAP HANA con HSR su SUSE Linux Enterprise Server

File Premium di Azure inizia con una quantità maggiore di operazioni di I/O al secondo con dimensioni di condivisione minime di 100 GB rispetto ad Azure NetApp Files. Questa barra più alta di operazioni di I/O al secondo può evitare il overprovisioning della capacità per ottenere determinati valori di operazioni di I/O al secondo e velocità effettiva. Per le operazioni di I/O al secondo e la velocità effettiva di archiviazione, leggere la sezione Obiettivi di ridimensionamento della condivisione file di Azure in Obiettivi di scalabilità e prestazioni di File di Azure.

La matrice di funzionalità per il carico di lavoro SAP è simile alla seguente:

Riepilogo: File Premium di Azure è una risorsa di archiviazione a bassa latenza che consente di distribuire volumi o condivisioni NFS e SMB. File Premium di Azure offre un ottimo rapporto prezzo/prestazioni per le condivisioni a livello di applicazione SAP. Fornisce anche la replica di zona sincrona per queste condivisioni. Finora non è supportato questo tipo di archiviazione per il carico di lavoro DBMS SAP. Anche se può essere usato per volumi /hana/shared.

Archiviazione SSD Standard di Azure

Rispetto all'archiviazione HDD standard di Azure, l'archiviazione SSD standard di Azure offre una migliore disponibilità, coerenza, affidabilità e latenza. È ottimizzata per carichi di lavoro che richiedono prestazioni coerenti a livelli di operazioni di I/O al secondo più bassi. Questa risorsa di archiviazione è l'archiviazione minima usata per i sistemi SAP non di produzione che hanno richieste di operazioni di I/O al secondo e velocità effettiva basse. La matrice di funzionalità per il carico di lavoro SAP è simile alla seguente:

Riepilogo: l'archiviazione SSD standard di Azure è la raccomandazione minima per le macchine virtuali non di produzione per il disco rigido virtuale di base, eventuali distribuzioni DBMS con relativa insensibilità alla latenza e/o frequenze di operazioni di I/O al secondo e velocità effettiva basse. Questo tipo di archiviazione di Azure non è più supportato per l'hosting della directory di trasporto globale SAP.

Archiviazione HDD Standard di Azure

L'archiviazione HDD Standard di Azure era l'unico tipo di archiviazione quando l'infrastruttura di Azure è stata certificata per il carico di lavoro SAP NetWeaver nell'anno 2014. Nell'anno 2014, le macchine virtuali di Azure erano piccole e con una velocità effettiva di archiviazione ridotta. Pertanto, questo tipo di archiviazione è stato in grado di mantenere il passo con le richieste. L'archiviazione è ideale per carichi di lavoro insensibili alla latenza, che difficilmente si riscontrano nello spazio SAP. Con l'aumento della velocità effettiva delle macchine virtuali di Azure e l'aumento del carico di lavoro che queste macchine virtuali producono, questo tipo di archiviazione non viene più considerato per l'utilizzo con scenari SAP. La matrice di funzionalità per il carico di lavoro SAP è simile alla seguente:

Riepilogo: HDD Standard è un tipo di archiviazione di Azure che deve essere usato solo per archiviare i backup SAP. Deve essere usato solo come disco rigido virtuale di base per sistemi piuttosto inattivi, come i sistemi ritirati usati per cercare i dati in diverse posizioni. Tuttavia, nessuna macchina virtuale di produzione, controllo di qualità o sviluppo attivo deve essere basata su questa risorsa di archiviazione, né deve essere usata per l'hosting dei file di database.

Limiti delle macchine virtuali di Azure nel traffico di archiviazione

A differenza degli scenari locali, il singolo tipo di macchina virtuale selezionato svolge un ruolo fondamentale nella larghezza di banda di archiviazione che è possibile ottenere. Per i diversi tipi di archiviazione, è necessario prendere in considerazione:

Come limitazioni, è necessario notare che:

• Quanto più le dimensioni della macchina virtuale sono ridotte, minore è il numero di dischi collegabili. Questa restrizione non si applica ad Azure NetApp Files. Poiché si montano condivisioni NFS o SMB, non viene rilevato un limite di numero di volumi condivisi da collegare
• Le macchine virtuali hanno limiti di operazioni di I/O al secondo e velocità effettiva di I/O che possono essere facilmente superati con dischi di archiviazione Premium e dischi Ultra.
• Con Azure NetApp Files e File Premium di Azure, il traffico verso i volumi condivisi usa la larghezza di banda di rete della macchina virtuale e non la larghezza di banda di archiviazione
• Con volumi NFS di grandi dimensioni nello spazio di capacità TiB a due cifre, la velocità effettiva di accesso a un volume di questo tipo da una singola macchina virtuale è destinato a raggiungere un livello massimo in base ai limiti di Linux per una singola sessione che interagisce con il volume condiviso.

Quando si ridimensionano le macchine virtuali di Azure durante il ciclo di vita di un sistema SAP, è necessario valutare i limiti di operazioni di I/O al secondo e velocità effettiva di archiviazione del tipo di macchina virtuale nuova e più grande. In alcuni casi, può anche essere utile modificare la configurazione di archiviazione in base alle nuove funzionalità della macchina virtuale di Azure.

Striping o non striping

La creazione di un set di striping da più dischi di Azure in un volume di dimensioni maggiori consente di accumulare le operazioni di I/O al secondo e la velocità effettiva dei singoli dischi in un unico volume. Viene usato solo per l'archiviazione Standard di Azure e per l'archiviazione Premium di Azure. Il disco Ultra di Azure, in cui è possibile configurare la velocità effettiva e le operazioni di I/O al secondo indipendentemente dalla capacità di un disco, non richiede l'utilizzo di set di striping. Non è possibile eseguire lo striping di volumi condivisi basati su NFS o SMB. A causa della natura non lineare della velocità effettiva e delle operazioni di I/O al secondo di Archiviazione Premium di Azure, è possibile effettuare il provisioning di capacità più piccole con le stesse operazioni di I/O al secondo e la stessa velocità effettiva rispetto a dischi di Archiviazione Premium di Azure di grandi dimensioni. Questo è il metodo per ottenere una velocità effettiva maggiore oppure operazioni di I/O al secondo a un costo inferiore usando Archiviazione Premium di Azure. Ad esempio, lo striping tra due dischi di Archiviazione Premium P15 consente di ottenere una velocità effettiva di:

• 250 MiB/sec. Un volume di questo tipo avrà una capacità di 512 GiB. Se si vuole avere un singolo disco che offre una velocità effettiva di 250 MiB al secondo, è necessario selezionare un disco P40 con capacità di 2 TiB.
• 400 MiB/sec tramite striping di quattro dischi di Archiviazione Premium P10 con una capacità complessiva di 512 GiB mediante striping. Se si vuole avere un singolo disco con una velocità effettiva minima di 500 MiB al secondo, è necessario selezionare un disco di Archiviazione Premium P60 con 8 TiB. Poiché il costo di Archiviazione Premium è quasi lineare con la capacità, è possibile percepire il risparmio sui costi usando lo striping.

Con lo striping devono essere seguite alcune regole:

• Non deve essere usata alcuna ridondanza di archiviazione configurata nella macchina virtuale perché Archiviazione di Azure mantiene ridondante il disco dati già nel back-end di Archiviazione di Azure
• I dischi a cui viene applicato il set di striping devono avere le stesse dimensioni
• Con SSD Premium v2 e il disco Ultra, la capacità, le operazioni di I/O al secondo con provisioning e la velocità effettiva con provisioning devono essere uguali

Lo striping tra più dischi di dimensioni inferiori è il modo migliore per ottenere un rapporto prezzo/prestazioni ottimale con Archiviazione Premium di Azure. È chiaro che lo striping può avere un sovraccarico aggiuntivo di distribuzione e gestione.

Per indicazioni specifiche sulle dimensioni di striping, leggere la documentazione per i diversi DBMS, ad esempio Configurazioni di archiviazione delle macchine virtuali di Azure con SAP HANA.

Passaggi successivi

Leggere gli articoli:

• Considerazioni sulla distribuzione DBMS di macchine virtuali di Azure per un carico di lavoro SAP
• Configurazioni dell'archiviazione di macchine virtuali di Azure in SAP HANA