Ottimizzare le prestazioni nelle macchine virtuali Linux serie Lsv3, Lasv3 e Lsv2

  • Articolo

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione Linux prossima allo stato EOL (End of Life, fine del ciclo di vita). Prendere in considerazione l'uso e il piano di conseguenza. Per altre informazioni, vedere le linee guida per la fine della vita di CentOS.

Si applica a: ✔️ macchine virtuali Linux ✔️ set di scalabilità uniformi

Le macchine virtuali di Azure serie Lsv3, Lasv3 e Lsv2 supportano vari carichi di lavoro che richiedono operazioni di I/O e velocità effettiva elevate nell'archiviazione locale in un'ampia gamma di applicazioni e settori. La serie L è ideale per i database Big Data, SQL, NoSQL, data warehousing e database transazionali di grandi dimensioni, tra cui Cassandra, MongoDB, Cloudera e Redis.

Sono disponibili diverse build di Azure Marketplace a causa della collaborazione con partner in Linux. Queste build sono ottimizzate per le prestazioni della serie Lsv3, Lasv3 e Lsv2. Le build disponibili includono le versioni seguenti e successive di:

  • Ubuntu 16.04
  • RHEL 8.0 e cloni, tra cui CentOS, Rocky Linux e Alma Linux
  • Debian 9
  • SUSE Linux 15
  • Oracle Linux 8.0

Questo articolo offre consigli e suggerimenti per garantire che i carichi di lavoro e le applicazioni raggiungano le prestazioni massime progettate nelle macchine virtuali.

Architettura del chipset AMD EPYC™

Le macchine virtuali serie Lasv3 e Lsv2 usano processori server AMD EPYC™ basati sulla microarchitettura Zen. AMD ha sviluppato Infinity Fabric (IF) per EPYC™ come interconnessione scalabile per il modello NUMA, che può essere usato per le comunicazioni su die, su pacchetto e su più pacchetti. Rispetto a QPI (Quick-Path Interconnection) e UPI (Ultra-Path Interconnect) usati nei moderni processori Intel con die monolitico, l'architettura con piccoli die e molti NUMA di AMD può comportare sia vantaggi in termini di prestazioni che sfide. L'impatto effettivo dei vincoli di larghezza di banda della memoria e latenza può variare a seconda del tipo di carico di lavoro in esecuzione.

Suggerimenti per ottimizzare le prestazioni

  • Se si carica un GuestOS Linux personalizzato per il carico di lavoro, la rete accelerata viene disattivata per impostazione predefinita. Se si intende abilitare la rete accelerata, abilitarla al momento della creazione della macchina virtuale per ottenere prestazioni ottimali.
  • Per ottenere prestazioni massime, eseguire più processi con profondità della coda per dispositivo.
  • Evitare di combinare i comandi di amministratore di NVMe (ad esempio, query di informazioni di NVMe SMART e così via) con i comandi di I/O di NVMe durante I carichi di lavoro attivi. I dispositivi NVMe Lsv3, Lasv3 e Lsv2 sono supportati dalla tecnologia Hyper-V NVMe Direct, che passa alla "modalità lenta" ogni volta che sono in sospeso tutti i comandi di amministratore di NVMe. Se ciò accade, gli utenti Lsv3, Lasv3 e Lsv2 potrebbero riscontrare un calo significativo delle prestazioni delle prestazioni di I/O NVMe.
  • Gli utenti di Lsv2 non devono basarsi sulle informazioni NUMA del dispositivo (pari a 0) segnalate dall'interno della macchina virtuale per le unità dati per stabilire l'affinità NUMA per le proprie app. Per ottenere prestazioni migliori è consigliabile distribuire i carichi di lavoro tra le CPU, se possibile.
  • La profondità massima della coda supportata per ogni coppia di code di I/O per il dispositivo NVMe Lsv3, Lasv3 e Lsv2 è 1024. Gli utenti di Lsv3, Lasv3 e Lsv2 devono limitare i carichi di lavoro di benchmarking (sintetico) a una profondità della coda di 1024 o inferiore per evitare di attivare le condizioni complete della coda, che possono ridurre le prestazioni.
  • Le prestazioni migliori si ottengono quando le operazioni di I/O vengono eseguite direttamente su ognuno dei dispositivi NVMe non elaborati senza partizionamento, senza file system, senza configurazione RAID e così via. Prima di avviare una sessione di test, verificare che la configurazione sia in uno stato aggiornato/pulito noto eseguendo blkdiscard in ogni dispositivo NVMe. Per ottenere le prestazioni più coerenti durante il benchmarking, è consigliabile condizionare in anticipo i dispositivi NVMe prima di eseguire test eseguendo scritture casuali in tutte le autorità di bilanciamento del carico di rete dei dispositivi due volte, come definito nella specifica di test delle prestazioni Enterprise SSD di SNIA.

Uso dell'archiviazione NVMe locale

L'archiviazione locale nel disco NVMe da 1,92 TB in tutte le macchine virtuali Lsv3, Lasv3 e Lsv2 è temporanea. Durante un riavvio standard della macchina virtuale con esito positivo, i dati sul disco NVMe locale vengono mantenuti. I dati non verranno mantenuti nei dispositivi NVMe se la macchina virtuale viene ridistribuita, deallocata o eliminata. I dati non verranno mantenuti se la macchina virtuale o l'hardware su cui è in esecuzione risulteranno non integri a causa di altri problemi. In tal caso, tutti i dati nell'host precedente vengono cancellati in modo sicuro.

In alcuni casi, ad esempio durante un'operazione di manutenzione pianificata, la macchina virtuale deve essere spostata in un computer host diverso. Le operazioni di manutenzione pianificata e alcuni errori hardware possono essere previsti con Eventi pianificati. Usare gli Eventi pianificati per rimanere aggiornati su eventuali operazioni di manutenzione e ripristino previste.

Nel caso in cui un evento di manutenzione pianificata richieda la ricreazione della macchina virtuale in un nuovo host con dischi locali vuoti, è necessario risincronizzare i dati (anche in questo caso, i dati dell'host precedente verranno cancellati in modo sicuro). Questo scenario si verifica perché le macchine virtuali della serie Lsv3, Lasv3 e Lsv2 non supportano attualmente la migrazione in tempo reale sul disco NVMe locale.

Sono disponibili due modalità per la manutenzione pianificata.

Manutenzione standard controllata dal cliente della macchina virtuale

  • La macchina virtuale viene spostata in un host aggiornato durante un periodo di 30 giorni.
  • I dati di archiviazione locale di Lsv3, Lasv3 e Lsv2 potrebbero andare perduti, quindi è consigliabile eseguire il backup dei dati prima dell'evento.

Manutenzione automatica

  • Si verifica se il cliente non esegue la manutenzione controllata dal cliente o in caso di procedure di emergenza, ad esempio un evento di sicurezza zero-day.
  • Progettata per mantenere i dati dei clienti, presenta tuttavia un piccolo rischio di blocco o riavvio di una macchina virtuale.
  • I dati di archiviazione locale di Lsv3, Lasv3 e Lsv2 potrebbero andare perduti, quindi è consigliabile eseguire il backup dei dati prima dell'evento.

Per eventuali eventi del servizio imminenti, usare il processo di manutenzione controllata per selezionare un orario più comodo per l'aggiornamento. Prima dell'evento, eseguire il backup dei dati nell'archiviazione Premium. Al termine dell'evento di manutenzione, è possibile restituire i dati all'archiviazione NVMe locale Lsv3, Lasv3 e Lsv2 aggiornata.

Ecco alcuni scenari in cui i dati sui dischi NVMe locali vengono mantenuti:

  • La macchina virtuale è integra e in esecuzione.
  • La macchina virtuale viene riavviata sul posto (dall'utente o da Azure).
  • La macchina virtuale viene sospesa (arrestata senza deallocazione).
  • La maggior parte delle operazioni di manutenzione pianificata.

Gli scenari che cancellano in modo sicuro i dati per proteggere il cliente includono:

  • La macchina virtuale viene ridistribuita, arrestata (deallocata) o eliminata (dall'utente).
  • La macchina virtuale diventa non integra ed è necessario correggere il servizio in un altro nodo a causa di un problema hardware.
  • Alcune delle operazioni di manutenzione pianificata che richiedono che la macchina virtuale venga riallocata a un altro host per la manutenzione.

Domande frequenti

Di seguito sono riportate le domande frequenti su queste serie.

Come si avvia la distribuzione di macchine virtuali serie L?

Come qualsiasi altra macchina virtuale, usare il Portale, l'interfaccia della riga di comando di Azure o PowerShell per creare una macchina virtuale.

Un singolo errore del disco NVMe causa l'esito negativo di tutte le macchine virtuali nell'host?

Se viene rilevato un errore del disco sul nodo hardware, quest'ultimo risulterà in stato di errore. Quando si verifica questo problema, tutte le macchine virtuali nel nodo vengono deallocate automaticamente e spostate in un nodo integro. Per le macchine virtuali serie Lsv3, Lasv3 e Lsv2, questo problema significa che i dati del cliente nel nodo non riuscito vengono cancellati in modo sicuro. Il cliente deve ricreare i dati nel nuovo nodo.

È necessario modificare le impostazioni di blk_mq?

RHEL/CentOS 7.x usa automaticamente blk-mq per i dispositivi NVMe. Non sono necessarie modifiche o impostazioni di configurazione.

Passaggi successivi

Vedere le specifiche per tutte le macchine virtuali ottimizzate per le prestazioni di archiviazione in Azure