soluzione Azure VMware considerazioni sulle prestazioni dell'archivio dati per Azure NetApp Files

Articolo
03/22/2024

Questo articolo fornisce considerazioni sulle prestazioni per soluzione Azure VMware progettazione e dimensionamento dell'archivio dati quando usato con Azure NetApp Files. Questo contenuto è applicabile a un amministratore di virtualizzazione, un cloud architect o un architetto di archiviazione.

Le considerazioni descritte in questo articolo consentono di ottenere i livelli più elevati di prestazioni dalle applicazioni con un'efficienza dei costi ottimizzata.

Azure NetApp Files offre un servizio di archiviazione scalabile, a prestazioni elevate e altamente affidabile per soluzione Azure VMware. I test includevano diverse configurazioni tra soluzione Azure VMware e Azure NetApp Files. I test sono stati in grado di guidare oltre 10.500 MiB/s e oltre 585.000 operazioni di input/output al secondo (IOPS) con solo quattro host soluzione Azure VMware/ESXi e un singolo pool di capacità di Azure NetApp Files.

Ottenere prestazioni di archiviazione più elevate per soluzione Azure VMware usando Azure NetApp Files

Il provisioning di più archivi dati, potenzialmente più grandi, a un livello di servizio può comportare un costo inferiore, garantendo allo stesso tempo prestazioni migliori. Il motivo è dovuto alla distribuzione del carico tra più flussi TCP da soluzione Azure VMware host a diversi archivi dati. È possibile usare l'archivio dati di Azure NetApp Files per soluzione Azure VMware TCO Estimator per calcolare potenziali risparmi sui costi caricando un report RVTools o immettendo il dimensionamento medio manuale delle macchine virtuali.

Quando si determina come configurare gli archivi dati, la soluzione più semplice dal punto di vista della gestione consiste nel creare un singolo archivio dati di Azure NetApp Files, montarlo e inserire tutte le macchine virtuali in . Questa strategia funziona bene per molte situazioni, fino a quando non è necessaria una maggiore velocità effettiva o operazioni di I/O al secondo. Per identificare i diversi limiti, i test hanno usato un generatore di carico di lavoro sintetico, il programma fio , per valutare un intervallo di carichi di lavoro per ognuno di questi scenari. Questa analisi consente di determinare come effettuare il provisioning dei volumi di Azure NetApp Files come archivi dati per ottimizzare le prestazioni e ottimizzare i costi.

Operazioni preliminari

Per i dati sulle prestazioni di Azure NetApp Files, vedere:

Azure NetApp Files: ottenere il massimo dall'archiviazione cloud

In un host soluzione Azure VMware viene stabilita una singola connessione di rete per ogni archivio dati NFS simile all'uso nconnect=1 nei test Linux a cui si fa riferimento nella sezione 6 (Opzioni di ottimizzazione). Questo fatto è fondamentale per comprendere come soluzione Azure VMware ridimensiona le prestazioni in modo ottimale in più archivi dati.
Benchmark delle prestazioni dell'archivio dati di Azure NetApp Files per la Soluzione Azure VMware

Metodologia di test

In questa sezione viene descritta la metodologia usata per i test.

Scenari di test e iterazioni

Questo test segue la metodologia "four-corner", che include sia operazioni di lettura che operazioni di scrittura per ogni input/output sequenziale e casuale (I/O). Le variabili dei test includono host uno-a-molti soluzione Azure VMware, archivi dati di Azure NetApp Files, macchine virtuali (per host) e dischi vm (VMDK) per ogni macchina virtuale. Sono stati selezionati i punti dati di ridimensionamento seguenti per trovare la velocità effettiva massima e le operazioni di I/O al secondo per gli scenari specificati:

Ridimensionamento di VMDK, ognuno nel proprio archivio dati per una singola macchina virtuale.
Scalabilità del numero di macchine virtuali per host in un singolo archivio dati di Azure NetApp Files.
Scalabilità del numero di host soluzione Azure VMware, ognuno con una macchina virtuale che condivide un singolo archivio dati di Azure NetApp Files.
Scalabilità del numero di archivi dati di Azure NetApp Files, ognuno con una VMDK distribuita equamente tra gli host soluzione Azure VMware.

Il test di operazioni a blocchi di piccole e grandi dimensioni e l'iterazione tramite carichi di lavoro sequenziali e casuali garantiscono il test di tutti i componenti negli stack di calcolo, archiviazione e rete nel "edge". Per coprire i quattro angoli con dimensioni del blocco e casualizzazione, vengono usate le seguenti combinazioni comuni:

Test sequenziali di 64 KB
- I carichi di lavoro di streaming di file di grandi dimensioni in genere leggono e scrivono in blocchi di grandi dimensioni, nonché le dimensioni predefinite dell'extent MSSQL.
- I test a blocchi di grandi dimensioni producono in genere la velocità effettiva più elevata (in MiB/s).
8 KB di test casuali
- Questa impostazione è la dimensione del blocco comunemente usata per il software di database, incluso il software di Microsoft, Oracle e PostgreSQL.
- I test a blocchi di piccole dimensioni producono in genere il numero più elevato di operazioni di I/O al secondo.

Nota

Questo articolo illustra solo i test di Azure NetApp Files. Non copre lo spazio di archiviazione vSAN incluso in soluzione Azure VMware.

Dettagli ambiente

I risultati di questo articolo sono stati ottenuti usando la configurazione dell'ambiente seguente:

soluzione Azure VMware host:
- Dimensioni: AV36
- Numero host: 4
- VMware ESXi versione 7u3
soluzione Azure VMware connettività cloud privato: gateway UltraPerformance con FastPath
Macchine virtuali guest:
- Sistema operativo: Ubuntu 20.04
- CPU/memoria: 16 vCPU / 64 GB di memoria
- Controller SCSI sas LSI virtuale con disco del sistema operativo da 16 GB in soluzione Azure VMware archivio dati vSAN
- Controller SCSI paravirtuale per i vmDK di test
- Configurazioni LVM/Disco:
  - Un volume fisico per disco
  - Un gruppo di volumi per volume fisico
  - Una partizione logica per gruppo di volumi
  - Un file system XFS per partizione logica
soluzione Azure VMware al protocollo Azure NetApp Files: NFS versione 3
Generatore di carichi di lavoro: fio versione 3.16
Script Fio: fio-parser

Risultati del test

In questa sezione vengono descritti i risultati dei test eseguiti.

Scalabilità a macchina virtuale singola

Quando si configura l'archiviazione presentata dall'archivio dati in una macchina virtuale soluzione Azure VMware, è consigliabile considerare l'impatto del layout del file system. La configurazione di più VMDK distribuite in più archivi dati offre la massima quantità di larghezza di banda disponibile. La configurazione di VMDK uno-a-molti posizionati in un singolo archivio dati garantisce la massima semplicità quando si tratta di backup e operazioni di ripristino di emergenza, ma a un costo inferiore del limite di prestazioni. I dati empirici forniti in questo articolo consentono di prendere decisioni.

Per ottimizzare le prestazioni, è comune ridimensionare una singola macchina virtuale tra più VMDK e posizionare tali VMDK in più archivi dati. Una singola macchina virtuale con solo uno o due VMDK può essere limitata da un archivio dati NFS mentre viene montato tramite una singola connessione TCP a un determinato host soluzione Azure VMware.

Ad esempio, i tecnici spesso eseguono il provisioning di una VMDK per un log del database e quindi effettuano il provisioning di VMDK uno-a-molti per i file di database. Con più VMDK sono disponibili due opzioni. La prima opzione consiste nell'usare ogni VDMK come singolo file system. La seconda opzione consiste nell'usare un'utilità di gestione dell'archiviazione, ad esempio LVM, filegroup MSSQL o Oracle ASM per bilanciare l'I/O tramite striping tra VMDK. Quando le VMDK vengono usate come singoli file system, la distribuzione di carichi di lavoro in più archivi dati è un'operazione manuale e può essere complessa. L'uso delle utilità di gestione dell'archiviazione per distribuire i file tra VMDK consente la scalabilità del carico di lavoro.

Se si esegue lo striping dei volumi tra più dischi, assicurarsi che il software di backup o il software di ripristino di emergenza supporti il backup di più dischi virtuali contemporaneamente. Poiché le singole scritture vengono stripate su più dischi, il file system deve assicurarsi che i dischi siano "bloccati" durante le operazioni di snapshot o backup. La maggior parte dei file system moderni include un'operazione di blocco o snapshot, ad xfs esempio (xfs_freeze) e NTFS (copie shadow del volume), che il software di backup può sfruttare.

Per comprendere il livello di scalabilità di una singola macchina virtuale soluzione Azure VMware man mano che vengono aggiunti più dischi virtuali, i test sono stati eseguiti con uno, due, quattro e otto archivi dati (ognuno contenente un singolo VMDK). Il diagramma seguente mostra un singolo disco con una media di circa 73.040 operazioni di I/O al secondo (ridimensionamento dal 100% di scrittura/0% lettura, fino al 0% di scrittura/ 100% lettura). Quando questo test è stato aumentato a due unità, le prestazioni sono aumentate del 75,8% a 128.420 operazioni di I/O al secondo. L'aumento di fino a quattro unità ha cominciato a mostrare un calo dei rendimenti di una singola macchina virtuale, ridimensionata come testata, potrebbe eseguire il push. Il picco di operazioni di I/O al secondo osservate è stato di 147.000 operazioni di I/O al secondo con letture casuali al 100%.

Scalabilità a host singolo - Archivio dati singolo

Aumenta il numero di macchine virtuali che guidano le operazioni di I/O in un singolo archivio dati da un singolo host. Questo è dovuto al flusso di rete singolo. Quando si raggiungono prestazioni massime per un determinato carico di lavoro, è spesso il risultato di una singola coda usata lungo la strada per l'archivio dati NFS singolo dell'host tramite una singola connessione TCP. Usando una dimensione di blocco di 8 KB, le operazioni di I/O al secondo totali sono aumentate tra il 3% e il 16% durante il ridimensionamento da una macchina virtuale con una singola VMDK a quattro macchine virtuali con 16 VMDK totali (quattro per macchina virtuale, tutte in un singolo archivio dati).

L'aumento delle dimensioni dei blocchi (a 64 KB) per carichi di lavoro a blocchi di grandi dimensioni ha avuto risultati confrontabili, raggiungendo un picco di 2148 MiB/s (singola macchina virtuale, singola VMDK) e 2138 MiB/s (4 MACCHINE virtuali, 16 VMDK).

Scalabilità a host singolo: più archivi dati

Dal contesto di un singolo host soluzione Azure VMware, mentre un singolo archivio dati ha consentito alle macchine virtuali di guidare circa 76.000 operazioni di I/O al secondo, distribuendo i carichi di lavoro in due archivi dati, la velocità effettiva totale è aumentata del 76% in media. Il passaggio da due archivi dati a quattro ha comportato un aumento del 163% (oltre un archivio dati, un aumento del 49% da due a quattro) come illustrato nel diagramma seguente. Anche se ci sono stati ancora miglioramenti delle prestazioni, l'aumento di oltre otto archivi dati ha mostrato un calo dei rendimenti.

Scalabilità multi-host - Archivio dati singolo

Un singolo archivio dati da un singolo host ha prodotto oltre 2000 MiB/s di velocità effettiva sequenziale di 64 KB. La distribuzione dello stesso carico di lavoro tra tutti e quattro gli host ha prodotto un picco di guadagno del 135% che guida oltre 5000 MiB/s. Questo risultato rappresenta probabilmente il limite massimo di una singola velocità effettiva del volume di Azure NetApp Files.

La riduzione delle dimensioni del blocco da 64 KB a 8 KB e la ripetizione delle stesse iterazioni ha comportato quattro macchine virtuali che producono 195.000 operazioni di I/O al secondo, come illustrato nel diagramma seguente. Le prestazioni aumentano in base al numero di host e al numero di archivi dati, in quanto aumenta il numero di flussi di rete. Le prestazioni aumentano ridimensionando il numero di host moltiplicati per il numero di archivi dati, perché il conteggio dei flussi di rete è un fattore di tempo per gli archivi dati degli host.

Scalabilità multi-host: più archivi dati

Un singolo archivio dati con quattro macchine virtuali distribuite in quattro host ha prodotto oltre 5000 MiB/s di I/O sequenziale di 64 KB. Per carichi di lavoro più impegnativi, ogni macchina virtuale viene spostata in un archivio dati dedicato, producendo in totale più di 10.500 MiB/s, come illustrato nel diagramma seguente.

Per carichi di lavoro casuali di piccole dimensioni, un singolo archivio dati ha prodotto 195.000 operazioni di I/O al secondo casuali da 8 KB. Il ridimensionamento a quattro archivi dati ha prodotto oltre 530.000 operazioni di I/O al secondo casuali di 8.000.

Implicazioni e raccomandazioni

In questa sezione viene illustrato il motivo per cui la distribuzione delle macchine virtuali in più archivi dati offre notevoli vantaggi in termini di prestazioni.

Come illustrato nei risultati del test, le funzionalità delle prestazioni di Azure NetApp Files sono abbondanti:

Il test mostra che un archivio dati può guidare una media di circa 148.980 operazioni di I/O al secondo da 8 KB o ~4147 MiB/s con operazioni di I/O al secondo da 64 KB (media di tutti i test di scrittura%/lettura) da una configurazione a quattro host.
Una macchina virtuale in un archivio dati:
- Se si dispone di singole macchine virtuali che potrebbero richiedere più di 75.000 operazioni di I/O al secondo da 8 KB o oltre 1700 MiB/s, distribuire i file system su più VMDK per ridimensionare le prestazioni di archiviazione delle macchine virtuali.
Una macchina virtuale in più archivi dati: una singola macchina virtuale in 8 archivi dati ha raggiunto fino a circa 147.000 operazioni di I/O al secondo da 8 KB o ~2786 MiB/s con dimensioni di blocco di 64 KB.
Un host: ogni host è stato in grado di supportare una media di circa 198.060 operazioni di I/O al secondo da 8 KB o ~2351 MiB/s se si usano almeno 4 macchine virtuali per host con almeno 4 archivi dati di Azure NetApp Files. È quindi possibile bilanciare il provisioning di archivi dati sufficienti per il massimo, il bursting, le prestazioni e la complicazione della gestione e dei costi.

Consigli

Quando le funzionalità delle prestazioni di un singolo archivio dati non sono sufficienti, distribuire le macchine virtuali in più archivi dati per aumentare ulteriormente la scalabilità. La semplicità è spesso ottimale, ma le prestazioni e la scalabilità possono giustificare la complessità aggiunta ma limitata.

Quattro archivi dati di Azure NetApp Files offrono fino a 10 GBps di larghezza di banda utilizzabile per operazioni di I/O sequenziali di grandi dimensioni o la capacità di gestire fino a 500.000 operazioni di I/O al secondo casuali da 8.000.000. Anche se un archivio dati può essere sufficiente per molte esigenze di prestazioni, per ottenere prestazioni ottimali, iniziare con un minimo di quattro archivi dati.

Per l'ottimizzazione granulare delle prestazioni, sia i sistemi operativi guest Windows che Linux consentono lo striping tra più dischi. Di conseguenza, è necessario eseguire lo striping dei file system tra più VMDK distribuiti in più archivi dati. Tuttavia, se la coerenza degli snapshot dell'applicazione è un problema e non può essere superata con l'LVM o gli spazi di archiviazione, valutare la possibilità di montare Azure NetApp Files dal sistema operativo guest o analizzare il ridimensionamento a livello di applicazione, di cui Azure offre molte opzioni eccezionali.

Se si esegue lo striping dei volumi tra più dischi, assicurarsi che il software di backup o il software di ripristino di emergenza supporti il backup di più dischi virtuali contemporaneamente. Poiché le singole scritture vengono distribuite su più dischi, il file system deve assicurarsi che i dischi siano "bloccati" durante le operazioni di snapshot o backup. La maggior parte dei file system moderni include un'operazione di blocco o snapshot, ad esempio xfs (xfs_freeze) e NTFS (copie shadow del volume), che il software di backup può sfruttare.

Poiché Azure NetApp Files fattura la capacità con provisioning nel pool di capacità anziché la capacità allocata (archivi dati), ad esempio si paga lo stesso per gli archivi dati da 4x20 TB o per gli archivi dati da 20x4 TB. Se necessario, è possibile modificare la capacità e le prestazioni degli archivi dati su richiesta, in modo dinamico tramite l'API o la console di Azure.

Ad esempio, quando si avvicina la fine di un anno fiscale si scopre che sono necessarie prestazioni di archiviazione più elevate nell'archivio dati Standard. È possibile aumentare il livello di servizio degli archivi dati per un mese per consentire a tutte le macchine virtuali in tali archivi dati di ottenere prestazioni più elevate, mantenendo al tempo stesso altri archivi dati a un livello di servizio inferiore. Non solo si risparmiano costi, ma si ottengono maggiori prestazioni grazie alla distribuzione di carichi di lavoro tra più connessioni TCP tra ogni archivio dati e ogni host AVS.

È possibile monitorare le metriche dell'archivio dati tramite il server vCenter o tramite l'API/console di Azure. Dal server vCenter è possibile monitorare le operazioni di I/O al secondo medio aggregato di un archivio dati nei grafici prestazioni/avanzati, purché si abiliti la raccolta delle metriche di controllo I/O di archiviazione nell'archivio dati. L'API di Azure e la console presentano le metriche per WriteIops, ReadIops, ReadThroughpute WriteThroughput, tra le altre, per misurare i carichi di lavoro a livello di archivio dati. Con le metriche di Azure è possibile impostare regole di avviso con azioni per ridimensionare automaticamente un archivio dati tramite una funzione di Azure, un webhook o altre azioni.

Condividi tramite