Gestione delle performance con QoS ONTAP
Suggerisci modifiche
PDF
La gestione sicura ed efficiente di più database Oracle richiede un'efficace strategia di QoS. Il motivo è rappresentato dalle funzionalità di performance in costante aumento offerte da un sistema storage moderno.
Nello specifico, la maggiore adozione dello storage all-flash ha permesso il consolidamento dei carichi di lavoro. Gli storage array che si affidano a supporti rotanti tendevano a supportare solo un numero limitato di workload i/o-intensive a causa delle limitate funzionalità IOPS della tecnologia delle unità rotazionali meno recente. Uno o due database altamente attivi saturerebbero i dischi sottostanti molto prima che gli storage controller raggiungano i loro limiti. Questo è cambiato. La capacità di performance di un numero relativamente contenuto di dischi SSD è in grado di saturare anche gli storage controller più potenti. Ciò significa che è possibile sfruttare tutte le funzionalità dei controller senza la paura di un improvviso crollo delle performance con picchi di latenza dei supporti rotanti.
Come esempio di riferimento, un semplice sistema ha AFF A800 a due nodi è in grado di fornire fino a un milione di IOPS casuali prima che la latenza superi un millisecondo. Ci si aspetta che pochissimi carichi di lavoro singoli raggiungano tali livelli. L'utilizzo completo di questo array di sistema AFF A800 implicherà l'hosting di più carichi di lavoro, per questo motivo in modo sicuro, garantendo al contempo la prevedibilità dei requisiti di qualità del servizio.
Esistono due tipi di qualità del servizio (QoS) in ONTAP: IOPS e larghezza di banda. È possibile applicare controlli di qualità del servizio a SVM, volumi, LUN e file.
QoS (IOPS)
Un controllo della qualità del servizio IOPS si basa ovviamente sugli IOPS totali di una data risorsa, ma esistono alcuni aspetti della qualità del servizio IOPS che potrebbero non essere intuitivi. Alcuni clienti sono rimasti colpiti dall'apparente aumento della latenza al raggiungimento di una soglia IOPS. L'aumento della latenza è il risultato naturale della limitazione degli IOPS. Logicamente, funziona in modo simile a un sistema token. Ad esempio, se un dato volume contenente file di dati ha un limite di 10K IOPS, ogni i/o che arriva deve prima ricevere un token per continuare l'elaborazione. Fino a quando non sono stati consumati più di 10K gettoni in un dato secondo, non sono presenti ritardi. Se le operazioni io devono attendere per ricevere il token, questa attesa viene visualizzata come latenza aggiuntiva. Più un carico di lavoro supera il limite di qualità del servizio, più a lungo ogni i/o deve attendere in coda per l'elaborazione del proprio turno, che appare all'utente come una latenza più elevata.
|
Prestare attenzione nell'applicazione dei controlli QoS ai dati dei log di transazione/ripristino del database. Mentre le richieste di performance del logging di redo sono in genere molto, molto più basse dei data afiles, l'attività del log di redo è molto bursty. L'io avviene in brevi impulsi e un limite QoS che appare appropriato per i livelli di io di redo medi potrebbe essere troppo basso per i requisiti effettivi. Il risultato può essere una serie di limitazioni delle performance, mentre la qualità del servizio viene associata a ogni burst dei log di ripristino. In generale, il redo e la registrazione dell'archivio non devono essere limitati dalla QoS. |
QoS della larghezza di banda
Non tutte le dimensioni i/o sono uguali. Ad esempio, un database potrebbe eseguire un elevato numero di piccoli blocchi di lettura con il raggiungimento della soglia IOPS, tuttavia, è possibile che i database eseguano anche un'operazione di scansione completa della tabella, che consisterebbe in un numero molto ridotto di letture di blocchi di grandi dimensioni, consumando una grande quantità di larghezza di banda ma con un numero relativamente basso di IOPS.
Allo stesso modo, un ambiente VMware potrebbe gestire un numero molto elevato di IOPS casuali durante l'avvio, ma eseguirebbe un numero minore di io, ma più grande, durante un backup esterno.
Una gestione efficace delle performance a volte richiede limiti di qualità del servizio (QoS) IOPS o larghezza di banda, o anche entrambi.
Qualità del servizio minima/garantita
Molti clienti cercano una soluzione che includa QoS garantita, che sia più difficile da raggiungere di quanto possa sembrare e che sia potenzialmente abbastanza dispendiosa. Ad esempio, collocare 10 database con una garanzia di 10K IOPS richiede il dimensionamento di un sistema per uno scenario in cui tutti i 10 database vengono eseguiti contemporaneamente a 10K IOPS, per un totale di 100K.
L'utilizzo ottimale per i controlli minimi della qualità del servizio è la protezione dei carichi di lavoro critici. Ad esempio, prendi in considerazione un controller ONTAP con un numero massimo di IOPS possibile di 500K e un mix di workload di produzione e sviluppo. È consigliabile applicare policy QoS massime ai carichi di lavoro di sviluppo per impedire a qualsiasi database di monopolizzare il controller. Quindi, ai carichi di lavoro di produzione si applicano policy minime di qualità del servizio per assicurarsi che dispongano sempre degli IOPS richiesti, quando necessario.
QoS adattiva
La qualità del servizio adattiva fa riferimento alla funzionalità ONTAP, in cui il limite della qualità del servizio si basa sulla capacità dell'oggetto storage. Viene utilizzata raramente con i database perché di solito non esiste alcun collegamento tra le dimensioni di un database e i relativi requisiti prestazionali. I database di grandi dimensioni possono essere quasi inerti, mentre quelli di dimensioni inferiori possono utilizzare un numero elevato di IOPS.
La qualità del servizio adattiva può rivelarsi molto utile con i datastore di virtualizzazione, perché i requisiti di IOPS di tali set di dati tendono a correlare le dimensioni totali del database. Un datastore più recente, che contiene 1TB TB di file VMDK, avrà probabilmente bisogno di circa la metà delle performance rispetto a un datastore da 2TB TB. La qualità del servizio adattiva ti consente di aumentare automaticamente i limiti della qualità del servizio, man mano che il datastore viene popolato con i dati.