Gestione IT

Tre funzioni di monitoraggio per i server virtualizzati VMware

22 Settembre 2014

La percentuale di server che vengono virtualizzati continua a crescere, ma la visibilità su di essi in termini di gestione continua a rappresentare una sfida.
In questo articolo daremo un'occhiata a tre tipologie di monitoraggio (il ferro, i datastore e le prestazioni) che vi possono fornire la visibilità e il controllo di cui avete bisogno per mantenere performanti le vostre applicazioni virtualizzate.


Prima di iniziare vediamo però una descrizione dei modelli di informazione rilevanti per la gestione degli hypervisor
 
Common Information Model

Common Information Model o CIM è uno standard aperto che definisce la gestione e il monitoraggio dei dispositivi e degli elementi dei dispositivi residenti in un datacenter.

VMware Infrastructure API

La VI API è un'implementazione proprietaria di CIM realizzata da VMware per la gestione e il monitoraggio dei componenti associati all'hypervisor VMware.


  1. Il ferro
  • Stato delle ventole: le ventole sono essenziali per il corretto funzionamento di un server.Quando la densità di un rack aumenta, il volume dei server diminuisce e le ventole devono girare a velocità più alte subendo quindi uno stress maggiore. Una ventola rotta può causare un rapido innalzamento della temperatura del server con conseguenze estese anche ai server circostanti. La buona notizia è che è relativamente facile monitorare lo stato di una ventola. La classe CIM_fan espone una proprietà denominata HealthState che contiene informazioni sullo stato di salute di una ventola: "OK, in stato degradato, guasta".
  • Stato degli alimentatori: monitorare lo stato di salute degli alimentatori è importante. La maggior parte dei server può essere configurata con alimentatori ridondanti; inoltre, è sempre una buona idea tenere da parte un'unità di ricambio. OMC_Powersupply è una classe che espone la proprietà HealthState di ciascun alimentatore di un server. Come per le ventole, anche un alimentatore può trovarsi in uno dei tre stati OK, degradato o guasto.
  • Consumi elettrici: la VI API può essere utilizzata per misurare i consumi medi di energia così da dare un'indicazione di quanto il server incida sul costo della bolletta elettrica. Più consumi implicano più calore, che porta a costi elettrici ulteriori sotto forma di dissipazione termica. I risultati del contatore power.power.average della VI API assumono il seguente aspetto:



 
  • Controller raid, storage e batteria tampone: tre elementi essenziali in ambito storage che andrebbero monitorati sono il raid controller, i volumi storage e la batteria. Il controller e i dischi sono elementi ovvi, ma la batteria? In molti casi i raid controller ad alte prestazioni possiedono una batteria tampone per conservare la memoria in caso di interruzione dell'alimentazione. La memoria del controller viene normalmente utilizzata come cache di write back, e quando il server non riceve più alimentazione la batteria assicura che la cache rimanga in uno stato consistente fino a quando l'alimentazione non viene ripristinata e i contenuti della memoria possono essere scritti su disco.
  1. Monitoraggio datastore

Utilizzo, IOP e latenza sono parametri che andrebbero monitorati e analizzati insieme.
Quando si verificano problemi di performance in un sottosistema a disco, una latenza in stato "Ok" può indicare che le cause potrebbero risiedere a livello di IOP.
Un utilizzo elevato può segnalare che il sistema non fornisce le IOP previste e così via.

  • Utilizzo: l'utilizzo può essere calcolato usando le proprietà capacity e freespace dell'oggetto DatastoreSummary.
  • IOP: il numero di operazioni di I/O al secondo può essere tenuto sotto controllo usando un contatore datastore.datastoreIops.average della VI API, che fornisce una media delle operazioni di I/O in lettura e scrittura.
  • Latenza: la latenza può essere misurata mediante i contatori datastore.totalWriteLatency.average e datastore.totalReadLatency.average, che mostrano i tempi medi di latenza in lettura e scrittura dell'intera catena dal kernel ai dispositivi.
  1. Monitoraggio delle prestazioni
  • I CPU thread schedulati per la CPU possono trovarsi in uno dei due stati: waiting o ready. Entrambi possono fornire indicazioni circa la carenza di risorse. La situazione meno problematica è lo stato wait, che segnala che il thread è in attesa del completamento di un'operazione di I/O: per esempio sta aspettando la risposta da una risorsa esterna dell'host oppure il termine di un'operazione su disco. Più serio invece è lo stato ready, perché significa che il thread sarebbe pronto per l'esecuzione ma non c'è CPU libera per poterlo servire.



 
  • Memory ballooning e IOPS: il cosiddetto memory ballooning è un processo che può avvenire quando l'host si trova in condizioni di poca memoria e richiede alle varie macchine virtuali di liberarla. Il balloon driver di ciascuna VM cerca di allocare quanta più memoria possibile all'interno della VM stessa (fino al 65% della memoria disponibile nella VM), dopo di che l'host procederà a liberarla per aggiungerla al proprio pool di memoria. Il contatore del memory ballooning, mem.vmmemctl.average, può segnalare quando questo accade. Come può dunque il memory ballooning influire sul grafico di IO? Dopo che l'host ha riconciliato la memoria liberata dalle VM, queste ultime possono iniziare a usare la propria memoria virtuale paginando blocchi di memoria su disco, motivo per il quale il memory ballooning può avviare un flusso di IO superiore al normale.
  • Memory swapping: il ballooning può avvenire anche quando non ci sono problemi particolari; è solo una strategia con la quale l'host si assicura che vi sia memoria libera a disposizione delle VM. Lo swapping della memoria a livello di host invece è invariabilmente un segnale di problemi. I contatori che occorre tenere sott'occhio sono i seguenti:
  1. mem.swapin.average;
  2. mem.swapout.average;
  3. mem.swapinRate.average;
  4. mem.swapoutRate.average.
Questi contatori indicano, in termini sia cumulativi che quantitativi, quanta memoria è soggetta a swap in/out.
Lo swapping della memoria dell'host è ancora più grave: non solo indica una situazione di carenza di memoria, ma anche conseguenti problemi nelle prestazioni IO.



In conclusione

Monitorare, documentare e notificare tutti questi parametri può essere una sfida.
La buona notizia per chi usa Kaseya è che si può implementare il monitoraggio descritto in questo articolo utilizzando il modulo Network Monitor di VSA 7.0.

Riferimenti e approfondimenti
 

(Tratto da Kaseya Blog)
Autore
Claudio Panerai
Gli ultimi prodotti che vi ho portato, nel 2020: Vade Secure Il primo sistema antispam/antihishing/antimalware basato sull'intelligenza artificiale e appositamente progettato per Office 365. Naturalmente a misura di MSP. ID Agent Piaffaforma che consente agli MSP di monitorare le credenziali (proprie e dei clienti) che sono in vendita nel dark web.
Nato a Ivrea nel 1969, è sposato e padre di due figlie. Laureato in Scienze dell’Informazione nel 1993, ha dapprima svolto numerose consulenze e corsi di formazione per varie società per poi diventare responsabile IT per la filiale italiana del più grande editore mondiale di informatica, IDG Communications. Dal 2004 lavora in Achab dapprima come Responsabile del Supporto Tecnico per poi assumere dal 2008 la carica di Direttore Tecnico. Giornalista iscritto all’albo dei pubblicisti, dal 1992 pubblica regolarmente articoli su riviste di informatica e siti web di primo piano. E' stimato da colleghi e clienti per la schiettezza e onestà intellettuale. Passioni: viaggi, lettura, cinema, Formula 1, sviluppo personale, investimenti immobiliari, forex trading. Claudio è anche su LinkedIn e Facebook.
Commenti (0)
Iscriviti
Notificami
guest
0 Commenti
Inline Feedbacks
Guarda tutti i commenti