Tipi di Archiviazione di Azure per carichi di lavoro SAP

  • Articolo

Azure offre numerosi tipi di archiviazione che differiscono notevolmente in funzionalità, velocità effettiva, latenza e prezzi. Alcuni tipi di archiviazione non sono utilizzabili o limitati per gli scenari SAP. Mentre diversi tipi di archiviazione di Azure 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 pubblici sono stati spostati per usare GiB (Gibibyte) o TiB (Tebibyte come unità di dimensione, invece di Gigabyte o Terabyte). Di conseguenza, tutta la documentazione di Azure e il prizing usano tali unità. Nel documento si fa riferimento esclusivamente a queste unità di dimensioni di Unità MiB, GiB e TiB. Potrebbe essere necessario pianificare con MB, GB e TB. Tenere quindi presente alcune piccole differenze nei calcoli se è necessario ridimensionare per una velocità effettiva di 400 MiB/sec, anziché una velocità effettiva 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 Disco Ultra mantiene il disco rigido virtuale di base (con sistema operativo) e i dischi dati collegati alle macchine virtuali in tre copie in 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 è trasparente. In seguito a 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 è predefinita per questi tipi di archiviazione in Azure. Azure NetApp Files garantisce una ridondanza sufficiente per assicurare gli stessi contratti di servizio di altre risorse di archiviazione di Azure native.

Esistono diversi metodi di ridondanza, tutti descritti nell'articolo Archiviazione di Azure replica applicabile ad alcuni dei diversi tipi di archiviazione offerti da Azure.

Nota

L'uso di Archiviazione di Azure per archiviare i dati del database e il file di log di rollforward, l'archiviazione con ridondanza locale è l'unico livello di resilienza supportato in questo momento

Tenere inoltre presente che diversi tipi di archiviazione di Azure influisce sui contratti di servizio di disponibilità delle singole macchine virtuali rilasciati nel contratto di servizio per Macchine virtuali.

Dischi gestiti di Azure

I dischi gestiti sono un tipo di risorsa in Azure Resource Manager che può essere usato invece dei dischi rigidi virtuali archiviati in account Archiviazione di Azure. Managed Disks è allineato automaticamente al [set di disponibilità][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.

Nota

È necessario che le nuove distribuzioni di macchine virtuali che usano l'archiviazione a blocchi di Azure per i dischi (tutte le risorse di archiviazione di Azure, ad eccezione di Azure NetApp Files e File di Azure) debbano usare i dischi gestiti di Azure per i dischi VHD/OS di base e i dischi dati che archiviano i file di database SAP. Indipendentemente dal fatto che le macchine virtuali siano distribuite tramite set di disponibilità, in zone di disponibilità o indipendenti dai set e dalle zone. I dischi usati per l'archiviazione delle copie di backup non devono necessariamente essere dischi gestiti.

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 elencano 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. Quindi, la volta successiva, si arresta e si riavvia la macchina virtuale, tutte le modifiche apportate prima ancora esistono. In particolare nei casi in cui la macchina virtuale viene distribuita da Azure in un altro host rispetto all'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 file comuni per processi EDI 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 del modo in cui usare i diversi tipi di archiviazione di Azure è documentata nell'articolo Quali tipi di disco sono disponibili in Azure?. Le raccomandazioni 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 certificati e supportati da SAP HANA, vedere l'articolo Configurazioni di archiviazione delle macchine virtuali di Azure SAP HANA.

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

Archiviazione scelte quando si usa la replica DBMS

Le architetture di riferimento prevedono l'utilizzo di funzionalità DBMS come SQL Server Always On, replica di sistema HANA, Db2 HADR 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.

Archiviazione raccomandazioni per scenari di archiviazione SAP

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

Scenario di utilizzo HDD Standard SSD Standard Archiviazione Premium SSD Premium v2 Disco Ultra Azure NetApp Files File Premium di Azure
Disco del sistema operativo Non adatto Idoneo con restrizioni (non prod) Consigliato Non possibile Non possibile Non possibile Non possibile
Directory di trasporto globale Non supportato Non supportato Consigliato Consigliato Consigliato Consigliato Raccomandazioni importanti
/sapmnt Non adatto Idoneo con restrizioni (non prod) Consigliato Consigliato Consigliato Consigliato Raccomandazioni importanti
Famiglie di macchine virtuali SAP HANA M/Mv2 del volume di dati DBMS Non supportato Non supportato Consigliato Consigliato Consigliato Consigliato2 Non supportato
Famiglie di macchine virtuali SAP HANA M/Mv2 del volume di log DBMS Non supportato Non supportato Consigliato1 Consigliato Consigliato Consigliato2 Non supportato
Volume di dati DBMS Famiglie di macchine virtuali SAP HANA Esv3/Edsv4 Non supportato Non supportato Consigliato Consigliato Consigliato Consigliato2 Non supportato
Famiglie di vm SAP HANA Esv3/Edsv4 del volume di log DBMS Non supportato Non supportato Non supportato Consigliato Consigliato Consigliato2 Non supportato
Volume condiviso HANA Non supportato Non supportato Consigliato Consigliato Consigliato Consigliato Consigliato3
Volume di dati DBMS non HANA Non supportato Idoneo con restrizioni (non prod) Consigliato Consigliato Consigliato Solo per versioni Oracle specifiche in Oracle Linux, Db2 e SAP A edizione Standard in SLES/RHEL Linux Non supportato
Famiglie di macchine virtuali M/Mv2 del volume del log DBMS non HANA Non supportato Idoneo con restrizioni (non prod) Consigliato1 Consigliato Consigliato Solo per versioni Oracle specifiche in Oracle Linux, Db2 e SAP A edizione Standard in SLES/RHEL Linux Non supportato
Famiglie di macchine virtuali non M/Mv2 del volume di log DBMS non HANA Non supportato idoneo con restrizioni (non prod) Adatto per un carico di lavoro fino a medio Consigliato Consigliato Solo per versioni Oracle specifiche in Oracle Linux, Db2 e SAP A edizione Standard in SLES/RHEL Linux Non supportato

1 Con l'uso dell'acceleratore di scrittura di Azure per le famiglie di macchine virtuali M/Mv2 per i volumi di log/rollforward

2 L'uso di ANF richiede che /hana/data e /hana/log siano in ANF

3 Finora testato solo su SLES

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

Scenario di utilizzo HDD Standard SSD Standard Archiviazione Premium SSD Premium v2 Disco Ultra Azure NetApp Files File Premium di Azure
Contratto di servizio per velocità effettiva/operazioni di I/O al secondo No No Sì Sì Sì Sì Sì
Letture di latenza Alto Da medio a alto Bassa submillisecond submillisecond submillisecond low
Scritture di latenza Alto Da medio a alto Basso (sottomillisecondo1) submillisecond submillisecond submillisecond low
HANA supportato No No Sì1 Sì Sì Sì No
Possibili snapshot del disco Sì Sì Sì No No Sì No
Allocazione di dischi in cluster di archiviazione diversi quando si usano set di disponibilità Tramite dischi gestiti Tramite dischi gestiti Tramite dischi gestiti Tipo di disco non supportato con le macchine virtuali distribuite tramite set di disponibilità Tipo di disco non supportato con le macchine virtuali distribuite tramite set di disponibilità No3 No
Allineato a zone di disponibilità Sì Sì Sì Sì Sì In anteprima pubblica No
Ridondanza della zona sincrona Non per i dischi gestiti Non per i dischi gestiti Non supportato per DBMS No No No Sì
Ridondanza della zona asincrona Non per i dischi gestiti Non per i dischi gestiti Non supportato per DBMS No No In anteprima No
Ridondanza geografica Non per i dischi gestiti Non per i dischi gestiti No No No Possibile No

1 Con l'uso dell'acceleratore di scrittura di Azure per le famiglie di macchine virtuali M/Mv2 per i volumi di log/rollforward

2 I costi dipendono dalle operazioni di I/O al secondo e dalla velocità effettiva di cui è stato effettuato il provisioning

3 La creazione di pool di capacità ANF diversi non garantisce la distribuzione di pool di capacità in unità di archiviazione diverse

Importante

Vedere la sezione Azure NetApp Files di questo documento per trovare specifiche relative alla posizione di prossimità dei volumi NFS e delle macchine virtuali quando sono necessarie latenze inferiori a 1 millisecondo.

Archiviazione Premium di Azure

L'archiviazione SSD Premium di Azure è stata introdotta con l'obiettivo di fornire:

  • 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. La base dei costi per l'archiviazione Premium di Azure non è il volume di dati effettivo archiviato in tali dischi, ma la categoria di dimensioni di tale disco, indipendentemente dalla quantità di dati archiviati all'interno del disco. È anche possibile creare dischi nell'archiviazione Premium che non vengono mappati direttamente nelle categorie di dimensioni illustrate nell'articolo SSD Premium. Le conclusioni di questo articolo sono:

  • Lo spazio di archiviazione è organizzato in intervalli. Ad esempio, un disco compreso nell'intervallo da 513 GiB a 1024 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 superiori a 32 GiB a 1024 GiB, la velocità di I/O al secondo per GiB è compresa tra 4 e 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 la categoria tra 65 GiB e 128 GiB, 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 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:

Funzionalità Comment Note/collegamenti
Disco rigido virtuale di base del sistema operativo Adatto Tutti i sistemi
Disco dati Adatto Tutti i sistemi - Specialmente per SAP HANA
Directory di trasporto globale SAP Sì Supportato
SAP sapmnt Adatto Tutti i sistemi
Archivio di backup Adatto Per l'archiviazione a breve termine dei backup
Condivisioni/disco condiviso Non disponibile Necessita di File Premium di Azure o di terze parti
Resilienza LRS Nessuna archiviazione con ridondanza geografica o archiviazione con ridondanza della zona disponibile per i dischi
Latenza Da basso a medio -
Contratto di servizio di I/O al secondo Sì -
Operazioni di I/O al secondo lineari per la capacità semi lineare tra parentesi quadre Prezzi di Managed Disk
Numero massimo di operazioni di I/O al secondo per disco 20.000 dipendenti dalle dimensioni del disco Prendere in considerazione anche i limiti delle macchine virtuali
Contratto di Servizio relativo al throughput Sì -
Velocità effettiva lineare alla capacità Semi lineare tra parentesi quadre Prezzi di Managed Disk
HANA certificato Sì appositamente per SAP HANA
Supporto dell'acceleratore di scrittura di Azure No -
Bursting del disco Sì -
Possibili snapshot del disco Sì -
Backup di Azure possibili snapshot di macchine virtuali Sì -
Costi Medio -

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 come 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 e le scritture di log di rollforward del log delle transazioni. È quindi consigliabile usarlo in tutte le distribuzioni DBMS DI 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 si applica ai sistemi non di produzione e 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 il overprovisioning della capacità di archiviazione. In alternativa, è necessario usare funzionalità come Spazi di Windows Archiviazione o gestioni volumi logici in Linux per creare set di striping che offrono la capacità desiderata su un lato. Ma anche le operazioni di I/O al secondo o la velocità effettiva necessarie al miglior costo.

Funzionalità di Azure per Archiviazione Premium in modalità burst

Per i dischi di archiviazione Premium di Azure più piccoli o uguali a 512 GiB nella 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 di Managed Disk). Si accumula il delta delle operazioni di I/O al secondo e della velocità effettiva tra l'utilizzo corrente e i valori nominale 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 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 di I/O submillisecond 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 di cui è stato effettuato il provisioning aggiuntivo
  • Passare la certificazione SAP HANA senza l'aiuto di altre funzionalità, ad esempio 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 la latenza submillisecond 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 operazioni di I/O al secondo non influisca principalmente sul prezzo. Tuttavia, è consigliabile decidere come verrà visualizzata la configurazione di archiviazione per SSD Premium v2. Per un avvio di base, leggere Le configurazioni di archiviazione PREMIUM v2 della macchina virtuale di Azure PER SAP HANA.

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

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

Funzionalità Comment Note/collegamenti
Disco rigido virtuale di base del sistema operativo Non supportato Nessun sistema
Disco dati Adatto Tutti i sistemi
Directory di trasporto globale SAP Sì Tutti i sistemi
SAP sapmnt Adatto Tutti i sistemi
Archivio di backup Adatto Per l'archiviazione a breve termine dei backup
Condivisioni/disco condiviso Non disponibile Richiede File Premium di Azure o Azure NetApp Files
Resilienza LRS Nessuna archiviazione con ridondanza geografica o archiviazione con ridondanza della zona disponibile per i dischi
Latenza submillisecond -
Contratto di servizio di I/O al secondo Sì -
Operazioni di I/O al secondo lineari per la capacità semi lineare Prezzi di Managed Disk
Numero massimo di operazioni di I/O al secondo per disco 80.000 dipendenti dalle dimensioni del disco Prendere in considerazione anche i limiti delle macchine virtuali
Contratto di Servizio relativo al throughput Sì -
Velocità effettiva lineare alla capacità Semi lineare Prezzi di Managed Disk
HANA certificato Sì -
Supporto dell'acceleratore di scrittura di Azure No -
Bursting del disco No -
Possibili snapshot del disco No -
Backup di Azure possibili snapshot di macchine virtuali No -
Costi Medio -

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 che si adatta al 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 del 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 andranno via 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 dei dischi Ultra includono la possibilità di modificare dinamicamente le operazioni di I/O al secondo e la velocità effettiva del disco, insieme ai carichi di lavoro, senza dover riavviare le macchine virtuali (VM). I dischi Ultra sono adatti per carichi di lavoro a elevato utilizzo di dati, ad esempio il carico di lavoro DBMS SAP. I dischi Ultra possono essere usati solo come dischi dati e non possono essere usati come disco rigido virtuale di base che archivia il sistema operativo. È consigliabile usare l'archiviazione Premium di Azure come disco rigido virtuale basato.

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

  • 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, vedere l'articolo Su 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, vedere l'articolo Su 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:

Funzionalità Comment Note/collegamenti
Disco rigido virtuale di base del sistema operativo Non funziona -
Disco dati Adatto Tutti i sistemi
Directory di trasporto globale SAP Sì Supportato
SAP sapmnt Adatto Tutti i sistemi
Archivio di backup Adatto Per l'archiviazione a breve termine dei backup
Condivisioni/disco condiviso Non disponibile Esigenze di terze parti
Resilienza LRS Nessuna archiviazione con ridondanza geografica o archiviazione con ridondanza della zona disponibile per i dischi
Latenza Molto bassa -
Contratto di servizio di I/O al secondo Sì -
Operazioni di I/O al secondo lineari per la capacità Semi lineare tra parentesi quadre Prezzi di Managed Disk
Numero massimo di operazioni di I/O al secondo per disco Da 1.200 a 160.000 dipendente dalla capacità del disco
Contratto di Servizio relativo al throughput Sì -
Velocità effettiva lineare alla capacità Semi lineare tra parentesi quadre Prezzi di Managed Disk
HANA certificato Sì -
Supporto dell'acceleratore di scrittura di Azure No -
Bursting del disco No -
Possibili snapshot del disco No -
Backup di Azure possibili snapshot di macchine virtuali No -
Costi Maggiore dell'archiviazione Premium -

Riepilogo: i dischi Ultra di Azure sono una risorsa di archiviazione adatta con bassa latenza submillisecond 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) Il disco Ultra non supporta gli snapshot di archiviazione. Invece di tutte le altre risorse di archiviazione, il disco Ultra non può essere usato per il disco VHD 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 in base ai modelli di carico di lavoro di archiviazione anziché ridimensionare per l'utilizzo massimo della larghezza di banda e delle operazioni di I/O al secondo.

Azure NetApp Files (ANF)

Azure NetApp Files è il risultato della collaborazione tra Microsoft e NetApp con l'obiettivo di fornire condivisioni NFS e SMB native di Azure ad alte prestazioni. L'accento è fornire una larghezza di banda elevata e un'archiviazione a bassa latenza che consente scenari di distribuzione DBMS e, nel corso del tempo, abilitare funzionalità operative tipiche dell'archiviazione NetApp anche tramite Azure. Le condivisioni NFS/SMB sono offerte in tre diversi livelli di servizio che differenziano la velocità effettiva di archiviazione e il prezzo. I livelli di servizio sono documentati nell'articolo Livelli di servizio per Azure NetApp Files. Per i diversi tipi di carico di lavoro SAP, è consigliabile usare i livelli di servizio seguenti:

  • Carico di lavoro DBMS SAP: prestazioni, idealmente Ultra
  • Condivisione SAPMNT: prestazioni, idealmente Ultra
  • Directory di trasporto globale: prestazioni, idealmente Ultra

Nota

La dimensione minima del provisioning è un'unità 4 TiB denominata pool di capacità. Si creano quindi volumi esterni a questo pool di capacità. Mentre il volume più piccolo che è possibile compilare è 100 GiB. È possibile espandere un pool di capacità nei passaggi TiB. Per i prezzi, vedere l'articolo Prezzi di Azure NetApp Files

L'archiviazione ANF è attualmente supportata per diversi scenari di carico di lavoro SAP:

Nota

Finora non sono supportati carichi di lavoro DBMS in SMB basati su Azure NetApp Files.

Come già con l'archiviazione Premium di Azure, una dimensione di velocità effettiva fissa o lineare per GB può essere un problema quando è necessario rispettare alcuni numeri minimi di velocità effettiva. Come questo è il caso di SAP HANA. Con ANF, questo problema può diventare più pronunciato rispetto al disco Premium di Azure. Usando il disco Premium di Azure, è possibile impiegare più dischi più piccoli con una velocità effettiva relativamente elevata per GiB e eseguire lo striping tra di essi per essere conveniente e avere una velocità effettiva più elevata a una capacità inferiore. Questo tipo di striping non funziona per le condivisioni NFS o SMB ospitate in ANF. Questa restrizione ha comportato la distribuzione dell'overcapacity, ad esempio:

  • Per ottenere, ad esempio, una velocità effettiva di 250 MiB/sec in un volume NFS ospitato in ANF, è necessario distribuire la capacità 1,95 TiB del livello di servizio Ultra.
  • Per ottenere 400 MiB/sec, è necessario distribuire la capacità 3.125 TiB. Tuttavia, potrebbe essere necessario il provisioning eccessivo della capacità per ottenere la velocità effettiva necessaria per il volume. Questo over-provisioning della capacità influisce sui prezzi delle istanze HANA più piccole.
  • Usando NFS sopra ANF per la directory SAP /sapmnt, in genere si raggiunge la capacità minima di 100 GiB a 150 GiB applicata da Azure NetApp Files. Tuttavia, l'esperienza del cliente ha dimostrato che la velocità effettiva correlata di 12,8 MiB/sec (usando il livello di servizio Ultra) potrebbe non essere sufficiente e potrebbe avere un impatto negativo sulla stabilità del sistema SAP. In questi casi, i clienti potrebbero evitare problemi aumentando il volume del volume /sapmnt, in modo che venga fornita una maggiore velocità effettiva a tale volume.

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

Funzionalità Comment Note/collegamenti
Disco rigido virtuale di base del sistema operativo Non funziona -
Disco dati Adatto SAP HANA, Oracle in Oracle Linux, Db2 e SAP A edizione Standard in SLES/RHEL
Directory di trasporto globale SAP Sì SMB e NFS
SAP sapmnt Adatto Tutti i sistemi SMB (solo Windows) o NFS (solo Linux)
Archivio di backup Adatto -
Condivisioni/disco condiviso Sì SMB 3.0, NFS v3 e NFS v4.1
Resilienza Archiviazione con ridondanza locale e archiviazione con ridondanza geografica Archiviazione con ridondanza geografica disponibile
Latenza Molto bassa -
Contratto di servizio di I/O al secondo Sì -
Operazioni di I/O al secondo lineari per la capacità rigorosamente lineare Dipendente dal livello di servizio
Contratto di Servizio relativo al throughput Sì -
Velocità effettiva lineare alla capacità lineare Dipendente dal livello di servizio
HANA certificato Sì -
Possibili snapshot del disco Sì -
Backup di Azure possibili snapshot di macchine virtuali No -
Costi Maggiore dell'archiviazione Premium -

Altre funzionalità predefinite dell'archiviazione ANF:

Importante

In particolare per le distribuzioni di database che si vogliono ottenere latenze basse per almeno i log di rollforward. In particolare per SAP HANA, SAP richiede una latenza inferiore a 1 millisecondo per le scritture di log di rollforward di HANA di dimensioni inferiori. Per arrivare a tali latenze, vedere le possibilità seguenti.

Importante

Anche per l'utilizzo non DBMS, è consigliabile usare la funzionalità di anteprima che consente di creare la condivisione NFS nella stessa zone di disponibilità di Azure in cui sono state inserite le macchine virtuali in cui montare le condivisioni NFS. Questa funzionalità è documentata nell'articolo Gestire il posizionamento del volume della zona di disponibilità per Azure NetApp Files. La motivazione di avere questo tipo di allineamento della zona di disponibilità è la riduzione della superficie di rischio avendo le condivisioni NFS ancora in un altro AvZone in cui non si eseguono macchine virtuali.

  • Si passa alla prossimità più vicina tra la condivisione VM e NFS che può essere disposta usando gruppi di volumi di applicazioni. Il vantaggio dei gruppi di volumi di applicazioni, oltre ad allocare la migliore prossimità e con tale latenza più bassa, è che le diverse condivisioni NFS per le distribuzioni SAP HANA vengono distribuite tra controller diversi nei cluster back-end di Azure NetApp Files. Lo svantaggio di questo metodo è che è necessario eseguire di nuovo un processo di aggiunta. Processo che finisce per limitare la distribuzione della macchina virtuale a un singolo data center. Anziché un zone di disponibilità come primo metodo introdotto. Ciò significa una minore flessibilità nella modifica delle dimensioni delle macchine virtuali e delle famiglie di macchine virtuali con volumi NFS montati.
  • Processo corrente di non utilizzo di gruppi di posizionamento di disponibilità. Che finora sono disponibili solo per SAP HANA. Questo processo usa anche lo stesso processo di aggiunta manuale, come nel caso dei gruppi di volumi di disponibilità. Questo metodo è il metodo utilizzato per gli ultimi tre anni. Ha le stesse restrizioni di flessibilità del processo con i gruppi di volumi di disponibilità.

Come preferenze per l'allocazione di volumi NFS basati su ANF per un utilizzo specifico del database, è necessario tentare di allocare prima il volume NFS nella stessa zona della macchina virtuale. In particolare per i database non HANA. Solo se la latenza risulta insufficiente, è consigliabile eseguire un processo di aggiunta manuale. Per un carico di lavoro HANA più piccolo o un carico di lavoro HANA non di produzione, è necessario seguire anche un metodo di allocazione di zona. Solo nei casi in cui le prestazioni e la latenza non sono sufficienti, è consigliabile usare gruppi di volumi di applicazioni.

Riepilogo: Azure NetApp Files è un'archiviazione a bassa latenza certificata HANA che consente di distribuire volumi o condivisioni NFS e SMB. L'archiviazione include tre diversi livelli di servizio che offrono velocità effettiva e operazioni di I/O al secondo in modo lineare per ogni capacità GiB del volume. La risorsa di archiviazione ANF consente di distribuire scenari scale-out SAP HANA con un nodo standby. È adatta per fornire le condivisioni file necessarie per la directory di trasporto globale SAP o /sapmnt. ANF garantisce la disponibilità delle funzionalità come funzionalità NetApp nativa.

File Premium di Azure

File Premium di Azure è un'archiviazione condivisa che offre SMB e NFS per un prezzo moderato e una latenza sufficiente per gestire le condivisioni del livello dell'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, un'altra replica in un'altra zona può assumere il controllo. Invece 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 sono stati testati come archiviazione DBMS per il carico di lavoro SAP. Ma lo scenario di utilizzo per il carico di lavoro SAP è incentrato su tutti i tipi di condivisioni SMB e NFS mentre vengono usati nel livello dell'applicazione SAP. File Premium di Azure è adatto anche per l'utilizzo di /hana/shared.

Nota

Finora non sono supportati carichi di lavoro DBMS SAP nei volumi condivisi basati su File Premium di Azure.

Scenari SAP supportati nell'elenco file Premium di Azure, ad esempio:

File Premium di Azure inizia con una quantità maggiore di operazioni di I/O al secondo con dimensioni minime di 100 GB rispetto ad Azure NetApp Files. Questa barra superiore 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 scalabilità delle condivisioni file di Azure in File di Azure obiettivi di scalabilità e prestazioni.

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

Funzionalità Comment Note/collegamenti
Disco rigido virtuale di base del sistema operativo Non funziona -
Disco dati Non supportato per i carichi di lavoro SAP -
Directory di trasporto globale SAP Sì SMB e NFS
SAP sapmnt Adatto Tutti i sistemi SMB (solo Windows) o NFS (solo Linux)
Archivio di backup Adatto -
Condivisioni/disco condiviso Sì SMB 3.0, NFS v4.1
Resilienza Archiviazione con ridondanza locale e archiviazione con ridondanza della zona Nessuna archiviazione con ridondanza geografica disponibile per File Premium di Azure
Latenza low -
Contratto di servizio di I/O al secondo Sì -
Operazioni di I/O al secondo lineari per la capacità rigorosamente lineare -
Contratto di Servizio relativo al throughput Sì -
Velocità effettiva lineare alla capacità rigorosamente lineare -
HANA certificato No -
Possibili snapshot del disco No -
Backup di Azure possibili snapshot di macchine virtuali No -
Costi low -

Riepilogo: File Premium di Azure è un'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 livello 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 i 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. È ottimizzato per i carichi di lavoro che richiedono prestazioni coerenti a livelli di I/O al secondo inferiori. Questa risorsa di archiviazione è l'archiviazione minima usata per sistemi SAP non di produzione con richieste di I/O al secondo e velocità effettiva basse. La matrice di funzionalità per il carico di lavoro SAP è simile alla seguente:

Funzionalità Comment Note/collegamenti
Disco rigido virtuale di base del sistema operativo Idoneo per restrizioni Sistemi non di produzione
Disco dati Idoneo per restrizioni Alcuni sistemi non di produzione con richieste di I/O al secondo e latenza basse
Directory di trasporto globale SAP No Non supportato
SAP sapmnt Idoneo per restrizioni Sistemi non di produzione
Archivio di backup Adatto -
Condivisioni/disco condiviso Non disponibile Esigenze di terze parti
Resilienza LRS, GRS Nessuna archiviazione con ridondanza della zona disponibile per i dischi
Latenza high Troppo elevato per la directory sap Global Transport o i sistemi di produzione
Contratto di servizio di I/O al secondo No -
Numero massimo di operazioni di I/O al secondo per disco 500 Indipendentemente dalle dimensioni del disco
Contratto di Servizio relativo al throughput No -
HANA certificato No -
Possibili snapshot del disco Sì -
Backup di Azure possibili snapshot di macchine virtuali Sì -
Costi LOW -

Riepilogo: l'archiviazione SSD standard di Azure è la raccomandazione minima per le macchine virtuali non di produzione per il disco rigido virtuale di base, le distribuzioni DBMS finali con latenza relativa e/o bassa velocità effettiva e/o operazioni di I/O al secondo e velocità effettiva. 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 è 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 ridotte e ridotte nella velocità effettiva di archiviazione. Pertanto, questo tipo di archiviazione è stato in grado di mantenere il passo con le richieste. L'archiviazione è ideale per i carichi di lavoro senza distinzione tra 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:

Funzionalità Comment Note/collegamenti
Disco rigido virtuale di base del sistema operativo Non adatto -
Disco dati Non adatto -
Directory di trasporto globale SAP No Non supportato
SAP sapmnt NO Non supportato
Archivio di backup Adatto -
Condivisioni/disco condiviso Non disponibile Esigenze File di Azure o di terze parti
Resilienza LRS, GRS Nessuna archiviazione con ridondanza della zona disponibile per i dischi
Latenza high Troppo elevato per l'utilizzo di DBMS, la directory sap Global Transport o sapmnt/saploc
Contratto di servizio di I/O al secondo No -
Numero massimo di operazioni di I/O al secondo per disco 500 Indipendentemente dalle dimensioni del disco
Contratto di Servizio relativo al throughput No -
HANA certificato No -
Possibili snapshot del disco Sì -
Backup di Azure possibili snapshot di macchine virtuali Sì -
Costi Bassa -

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 qui e lì. 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

Invece 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:

Tipo di archiviazione Linux Windows Commenti
Unità disco rigido Standard Dimensioni per le macchine virtuali Linux in Azure Dimensioni per le macchine virtuali Windows in Azure Probabilmente è difficile toccare i limiti di archiviazione di macchine virtuali di medie o grandi dimensioni
SSD Standard Dimensioni per le macchine virtuali Linux in Azure Dimensioni per le macchine virtuali Windows in Azure Probabilmente è difficile toccare i limiti di archiviazione di macchine virtuali di medie o grandi dimensioni
Archiviazione Premium Dimensioni per le macchine virtuali Linux in Azure Dimensioni per le macchine virtuali Windows in Azure È facile raggiungere i limiti di IOPS o velocità effettiva dell'archiviazione con la configurazione dell'archiviazione
SSD Premium v2 Dimensioni per le macchine virtuali Linux in Azure Dimensioni per le macchine virtuali Windows in Azure È facile raggiungere i limiti di IOPS o velocità effettiva dell'archiviazione con la configurazione dell'archiviazione
Archiviazione su disco Ultra Dimensioni per le macchine virtuali Linux in Azure Dimensioni per le macchine virtuali Windows in Azure È facile raggiungere i limiti di IOPS o velocità effettiva dell'archiviazione con la configurazione dell'archiviazione
Azure NetApp Files Dimensioni per le macchine virtuali Linux in Azure Dimensioni per le macchine virtuali Windows in Azure Archiviazione traffico usa la larghezza di banda della velocità effettiva di rete e non la larghezza di banda di archiviazione.
File Premium di Azure Dimensioni per le macchine virtuali Linux in Azure Dimensioni per le macchine virtuali Windows in Azure Archiviazione traffico usa la larghezza di banda della velocità effettiva di rete e non la larghezza di banda di archiviazione.

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 ANF. Poiché si montano condivisioni NFS o SMB, non viene rilevato un limite 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 ANF 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 che accede a un volume di questo tipo da una singola macchina virtuale sta per stabilizzarsi in base ai limiti di Linux per una singola sessione che interagisce con il volume condiviso.With large NFS volumes in the double digit of the double digit TiB capacity space, the throughput accessing such a such volume out of a single VM is going to plateau based on limits of Linux for a single session interacting with the shared volume.

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ù piccola con le stesse operazioni di I/O al secondo e la velocità effettiva rispetto a dischi di archiviazione Premium di Azure di grandi dimensioni. Questo è il metodo per ottenere una velocità effettiva maggiore o operazioni di I/O al secondo a un costo inferiore usando l'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 eseguendo lo striping di quattro dischi di archiviazione Premium P10 con una capacità complessiva di 512 GiB tramite 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 dell'archiviazione Premium è quasi lineare con la capacità, è possibile percepire il risparmio sui costi usando lo striping.

Alcune regole devono essere seguite sullo striping:

  • Non deve essere usata alcuna archiviazione configurata nella macchina virtuale perché l'archiviazione di Azure mantiene già ridondanti i dati
  • 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 di cui è stato effettuato il 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. Si è capito che lo striping può avere un sovraccarico aggiuntivo per la distribuzione e la gestione.

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

Passaggi successivi

Leggere gli articoli: