Tendenza accurata delle prestazioni I / O casuali per la pianificazione della capacità

Dove lavoro, abbiamo numerosi server "big iron" che vengono utilizzati per ospitare molte macchine virtuali utilizzando un Xen Hypervisor. Questi sono in genere configurati con 32 GB di RAM, processi core Dual Quad e dischi veloci con capacità I / O grandi.

Siamo nel momento in cui la configurazione hardware esistente sta diventando un po 'lunga ed è tempo di uscire e procurarsi un nuovo hardware più grande, più veloce e più brillante.

Come accennato in precedenza, il kit esistente è stato distribuito con 32 GB di RAM e ciò ha effettivamente limitato il numero di VM che è possibile distribuire su un host.

Indagando sull'hardware più recente, è evidente che è possibile ottenere sempre più RAM in un singolo computer con 64, 72 o addirittura 96 ​​GB all'interno di un singolo chassis. Evidentemente, questo ci consentirà di ottenere più macchine per un determinato host, che è sempre una vittoria. L'analisi completata finora suggerisce che il fattore limitante verrà ora spostato nel sottosistema del disco.

Il problema è ora, cercando di avere un'idea di dove siamo ... In virtù dell'uso, sappiamo che non siamo limitati in termini di larghezza di banda I / O, soprattutto, il numero di I casuali / O operazioni che possono essere completate. Sappiamo aneddoticamente che una volta raggiunto questo punto allora iowait salirà a razzo e l'intera performance della macchina andrà ai cani.

Ora questo è il punto cruciale della domanda che sto ponendo: qualcuno è a conoscenza di un modo per tracciare / tracciare con precisione le prestazioni degli I / O esistenti in particolare in relazione al numero di operazioni I / O casuali che vengono completate?

Quello su cui sto davvero cercando di ottenere una metrica è "questa configurazione può gestire con successo il numero X di richieste I / O casuali e attualmente stiamo (in media) eseguendo operazioni Y con un picco di operazioni Z".

Grazie in anticipo!

sarfa bene il lavoro qui; raccoglierà il numero di transazioni, nonché i settori letti / scritti al secondo, che possono essere utilizzati per riprodurre nuovamente il carico di lavoro di I / O con una precisione relativamente decente (in termini di rapporti di lettura / scrittura, nonché le dimensioni della transazione, che è il fattore determinante per quanto "casuale" sia il tuo IO). Non è perfetto, ma nella mia esperienza fa un lavoro abbastanza buono da fare il tipo di stima che stai guardando.

Quindi, questo sembra un problema di monitoraggio e reportistica della capacità. Se inizierai a misurare le statistiche di tendenza, andrei su tutta la linea, in modo da poter confrontare, correlare ecc.

In termini di strumenti, disponi di gangli, zenoss, nagios, ecc. Nel mondo open source e numerosi altri prodotti del fornitore.

Puoi configurarli per tracciare, misurare e archiviare gli indicatori KPI che ti interessano e quindi riferire periodicamente su di essi.

Date le tue domande sull'utilizzo della RAM, sarebbe logico includere anche le statistiche di memoria, l'utilizzo di swap e anche la CPU, in modo da poterle confrontare su tutta la linea per lo stesso periodo di tempo e vedere quale è limitato, ecc.

Una volta acquisiti i dati, è possibile archiviarli tutti in un bel database di grandi dimensioni per i report, eventualmente chiarendo i dati storici, ad es. memorizzare ogni metrica di 5 secondi per 6 mesi, quindi al minuto, quindi 5, quindi all'ora, mentre si procede più indietro. Questo genere di cose possono essere copiate ed eseguite tramite cron, autosys ecc.

Questi rapporti ti daranno ciò che la direzione desidera, ad es. qualcosa con bei grafici.

E per la gestione quotidiana puoi consultare le informazioni in tempo reale su un grafico / figure attraverso la console per vedere come ti stai esibendo in un dato momento.

Usiamo collectl in quanto possiamo raccogliere tutte le informazioni necessarie in un singolo file e riprodurre le statistiche quando necessario. Questo ti permetterà di vedere il numero di IOPS per intervallo di registrazione, cambi di contesto, statistiche di memoria. È possibile suddividere questo per disco o semplicemente dare un'occhiata al sistema. Collectl supporta anche la lucentezza.

Questo è un ottimo strumento per ottenere una panoramica delle prestazioni totali del sistema. Buona fortuna, dalle osservazioni i dischi SATA in genere superano tra 200-300 IOPS quando si esegue l'accesso casuale.

Registriamo e rappresentiamo graficamente l'I / O del disco nello stesso modo in cui eseguiamo tutte le altre metriche:

• I dati vengono estratti dagli host tramite SNMP. Le nostre scatole NAS / SAN lo fanno in modo nativo. Usiamo net-snmp su tutti gli host Linux, che fornisce queste informazioni da USB-DISKIO-MIB .

• I dati vengono archiviati (in formato RRD) e rappresentati graficamente tramite Cacti . Alcuni modelli di IO del disco ci forniscono un conteggio e dimensioni delle transazioni, visualizzati nel solito formato corrente, medio e di picco.

Queste metriche non sono necessariamente limitate come l'utilizzo di iostat/ dstat/ sarsu un host. Ma è il fuoco e dimentica, che si configura automaticamente quando una nuova macchina viene messa in servizio, memorizzata centralmente e rimane disponibile per riferimento futuro.

Utilizziamo questi dati per avvisarci di tendenze insolite su base operativa e ci guardiamo sempre indietro ogni volta che eseguiamo la pianificazione della capacità.

Quello su cui sto davvero cercando di ottenere una metrica è "questa configurazione può gestire con successo il numero X di richieste I / O casuali [..]".

Ci sono un paio di problemi con questo:

• È piuttosto difficile separare e quantificare l'I / O casuale dall'I / O sequenziale. Poiché la differenza fondamentale tra i due è la posizione fisica dei blocchi memorizzati sul piatto del disco. Puoi fare un'ipotesi approfondita dalla dimensione delle transazioni, sulla base del fatto che molte piccole transazioni si riferiscono probabilmente a piccoli file sparsi sul disco. Ma non c'è garanzia. Esso potrebbe essere la lettura piccole quantità di dati in modo sequenziale da un singolo file o blocchi adiacenti sul disco.

• La registrazione delle metriche ti darà un'ottima immagine di quali sono i tuoi impegni oggi, come sono cambiati nel tempo e quindi come cambieranno in futuro. Ciò che non ti dirà è il soffitto. Almeno non prima che sia troppo tardi. Per determinare questo è necessario fare alcuni calcoli (dalle specifiche hardware), benchmarking (sono affezionato a bonnie++me stesso) ed è utile avere un'idea logistica di ciò che fanno / vengono utilizzate quelle domU.

A seconda del back-end di archiviazione (IBM SVC / DS8000), è possibile estrarre direttamente le statistiche relative agli IOPS casuali.

Per estrarre le statistiche dal server, puoi usare nmon . È gratuito (come nella birra). Originariamente sviluppato da IBM per AIX, funziona anche su Linux.

Se le persone usano la SAR, almeno spero che stai campionando i tuoi dati ogni pochi secondi. Quando uso collectl, campiono una volta / secondo. Per quanto riguarda la misurazione del rendimento degli I / O casuali, utilizza uno strumento come il dt di Robin Miller (google it) e puoi facilmente generare MOLTO I / O casuali e poi misurare con collectl per vedere quanti può fare al secondo. Un disco tipico di solito esegue un massimo di 200-300 I / O / sec, basandosi praticamente sulla latenza di rotazione. La dimensione del blocco ha avuto un effetto minimo poiché l'attesa di 1/2 giro per il disco nella posizione corretta travolge tutto il resto.

btw - iowait è una delle misure più fraintese. Non ha NIENTE a che fare con il caricamento della CPU, significa solo che la CPU non stava facendo altro mentre si verificava l'I / O. In effetti, se sei al 100%, questo significa essenzialmente che sei inattivo al 100%!

-marchio