Molti nuovi clienti quando iniziano a utilizzare CloudSigma vogliono testare le prestazioni; spesso cercano di confrontare i risultati delle prestazioni tra i server cloud e la propria infrastruttura, e questo ha senso. Un semplice confronto dei prezzi per risorsa non racconta affatto tutta la storia; ciò che conta davvero è il risultato finale, quanto costa completare uno specifico compito di calcolo?
Per qualsiasi requisito, il numero di risorse necessarie per soddisfarlo può variare notevolmente tra i diversi cloud. Ciò significa che confrontare solo i prezzi non funziona. Il rovescio della medaglia è che confrontare le prestazioni in isolamento non è affatto meglio. I confronti significativi devono mettere insieme sia il prezzo che le prestazioni per calcolare una misura del costo per unità di calcolo. In questo post ho intenzione di condividere alcune delle mie riflessioni sul benchmarking dei nostri server cloud e di altri. Fornirò anche alcuni suggerimenti per ottenere risultati utili e sul loro reale significato.
Avvertenze
Per chiarire fin da subito, sono piuttosto scettico riguardo al benchmarking in generale. Raramente offre una reale visione dell’utilizzo nel mondo reale. In breve, non c’è un vero sostituto all’esecuzione delle applicazioni effettive che si intende utilizzare sulla piattaforma. Se si riesce a raggiungere questo obiettivo a un costo ragionevole in termini di tempo, allora non c’è alcun sostituto per un simile esercizio.
Un altro fattore è quanto sia occupato il fornitore di cloud. Potreste testare i server cloud e ottenere risultati eccellenti. Tuttavia, questi potrebbero essere in gran parte dovuti al livello di utilizzo (o alla mancanza di esso) di quel particolare fornitore. Questo potrebbe non essere un segno positivo. Potrebbe riflettere difficoltà operative, perdita di clienti, problemi passati con la disponibilità e l’affidabilità, ecc. Dovreste sempre, quindi, fare ricerche sul fornitore di cloud per verificare interruzioni passate e altri potenziali problemi quando interpretate i risultati dei loro benchmark.
Come ultima avvertenza, le prestazioni non sono l’unico fattore da considerare. Spesso prestazioni inferiori possono riflettere un’architettura hardware sottostante più robusta (e ridondante). È sempre importante, quindi, avere una comprensione molto chiara dell’infrastruttura su cui è costruito il cloud. In questo modo, potrete confrontare i risultati in modo equo, consentendovi di prendere una decisione d’acquisto consapevole.
Definire il problema
Più avanti in questo post, illustrerò i vari aspetti delle prestazioni e il modo migliore per interpretare i risultati. Prima di effettuare qualsiasi benchmarking, tuttavia, è importante caratterizzare il tipo di calcolo che si intende eseguire nel cloud; questo determinerà l’importanza relativa delle diverse metriche di prestazione. Ad esempio, se si desidera posizionare un server di database che sarà sottoposto a un pesante accesso in lettura ma a un basso accesso in scrittura, si dovrebbe prestare attenzione alle prestazioni del disco nel cloud e in particolare all’accesso in lettura non sequenziale.
Quindi, prima di iniziare qualsiasi benchmarking dei server cloud, codificate effettivamente ciò che considerereste una buona prestazione da parte del cloud. Dovreste determinare quali aspetti sono fondamentali e hanno un impatto sproporzionato sulle prestazioni reali del vostro sistema di calcolo. Una volta che avrete un’idea chiara di questo, sarete in grado di iniziare a valutare il benchmarking.
Prestazioni computazionali
Quando consideriamo le prestazioni computazionali grezze, parliamo di CPU e RAM. Le differenze di prestazioni a livello puramente computazionale tra i vari cloud non sono in realtà così grandi. Tuttavia, ci sono alcuni fattori che causano le vere differenze.
Di gran lunga il fattore principale che influenza le prestazioni computazionali nel cloud è la contesa. I cloud pubblici sono ambienti multi-tenant. La RAM e lo storage non possono essere effettivamente sovra-allocati (anche se possono essere sovra-venduti), ma la CPU può esserlo e lo è. I livelli di contesa variano notevolmente, ma essenzialmente i fornitori di cloud pubblico sono in grado di vendere la capacità della CPU di un host fisico a più del 100%.
Alcuni dei più grandi fornitori utilizzano rapporti di contesa della CPU superiori a tre volte. Ciò significa che la capacità totale di CPU ‘venduta’ di tutti i server virtuali sulla stessa macchina fisica potrebbe essere tre volte la sua capacità di CPU effettiva. Fanno questo perché la maggior parte dei server virtuali non utilizza quasi mai il 100% della propria allocazione di CPU per la maggior parte del tempo. Tuttavia, i rapporti di contesa influenzeranno direttamente i benchmark delle prestazioni dei server cloud e l'utilizzo nel mondo reale. Se la contesa è elevata (ovvero a un'allocazione della CPU superiore al 200%), le prestazioni del server cloud deterioreranno in modo significativo.
In parole povere, se il carico su qualsiasi macchina fisica supera 1 per core, le attività di calcolo vengono messe in coda e il tempo impiegato da quella macchina virtuale per completare il lavoro sarà più lungo. Dato che la maggior parte dei cloud addebita i costi in base alla capacità/ora, ciò ha un impatto diretto sui costi per i clienti di quel cloud.
L'altro fattore importante che influenza le prestazioni di calcolo è il numero di core CPU a cui la macchina virtuale ha accesso. Questo non è un fattore per tutte le applicazioni, ma molte applicazioni moderne supportano il multi-threading. In pratica, ciò significa che l'applicazione e/o il sistema operativo sono in grado di distribuire le attività di calcolo su più core. Un ottimo consiglio per migliorare le prestazioni del tuo calcolo consiste nel far corrispondere il numero di thread (ovvero core) che un'applicazione può supportare al numero di core a cui la macchina virtuale ha accesso.
Sfortunatamente, questo non è possibile con molti cloud pubblici. Questo perché le loro piattaforme di virtualizzazione non supportano la virtualizzazione a livello di core della CPU. In altre parole, ogni core può essere utilizzato da una sola macchina virtuale alla volta. Nei cloud che supportano la virtualizzazione dei core della CPU, dovresti sperimentare variando il numero di core per quella macchina mantenendo invariata la dimensione totale della CPU.
Ad esempio, se hai una macchina da 2 GHz puoi vedere come il raddoppio dei core in uso da due a quattro influisca sul tuo benchmarking. In questo modo, le applicazioni in esecuzione su quella macchina virtuale saranno in grado di eseguire attività tramite quattro core contemporaneamente. Nel nostro caso, puoi impostare il numero di core utilizzati da una macchina virtuale tramite la scheda ‘avanzate’ nel modulo dei dettagli del server della console web. Ricorda solo di controllare sempre qual è la dimensione standard del core del fornitore cloud prima di sovrascrivere manualmente il numero di core in uso. Nel nostro caso è di 2,2 GHz per core, ma varia da cloud a cloud.
Consiglierei di prendere in considerazione l'uso di POV-RAY, CoreMark, Dhrystone o Whetstone per il benchmarking delle prestazioni dei server cloud.
Archiviazione: il vero benchmark delle prestazioni dei server cloud
Tutte le prestazioni sono limitate dall'anello più debole in cui si sviluppa un collo di bottiglia. Attualmente, la tecnologia ha fatto notevoli progressi nel campo della virtualizzazione per quanto riguarda l'uso di CPU e RAM. Ad esempio, una singola macchina fisica può essere virtualizzata e ospitare più server cloud con una perdita minima delle prestazioni complessive aggregate. Purtroppo, nel caso dell'archiviazione, c'è ancora molta strada da fare. Il risultato finale è che, nella maggior parte dei casi, le prestazioni dei server virtuali nel cloud sono determinate dalle prestazioni della soluzione di archiviazione di quel cloud.
In breve, l'archiviazione è attualmente il fattore limitante per le prestazioni della maggior parte delle attività di calcolo nel cloud. Indipendentemente dai risultati che POV-Ray e altri benchmark possono produrre per le attività di calcolo puro, la realtà è che la velocità con cui il server virtuale può recuperare e scrivere dati sui dischi di archiviazione fisici determinerà le prestazioni reali di un server cloud attuale.
Con questo in mente, le reali differenze riscontrate nelle prestazioni nel cloud, anche per quanto riguarda le attività di calcolo, tendono a derivare dalle differenze nelle prestazioni di archiviazione. Come accennato in precedenza in questo post, ci sono esigenze dei clienti molto diverse a seconda dell'attività di calcolo. Questo non è mai così vero come per quanto riguarda l'archiviazione. Avete bisogno di un accesso rapido in lettura a grandi blocchi sequenziali di dati (come lo streaming multimediale) o a piccole informazioni disparate (forse in un grande database)? Avete bisogno di sostenere un pesante accesso in scrittura per dati in rapida evoluzione a cui si accede periodicamente in grandi picchi? Esistono numerosi scenari e ognuno si comporterà in modo diverso sulla stessa piattaforma.
Fondamentalmente, le differenze di prestazioni si riducono all'architettura. Tali differenze nell'architettura derivano solitamente da diversi gradi di robustezza rispetto alla memorizzazione dei dati, alla loro ridondanza e quindi, di fatto, alla probabilità di andare persi irreparabilmente. Ad alto livello, i cloud utilizzano soluzioni di dati centralizzate sotto forma di una Storage Area Network (SAN) o soluzioni di archiviazione locale più distribuite. In queste, l'archiviazione si trova su ogni singola macchina fisica.
Le buone SAN hanno intrinsecamente un alto livello di ridondanza integrato. Tuttavia, le prestazioni ne risentono poiché i dati devono essere inviati dalla SAN attraverso la rete alla CPU e alla RAM della macchina virtuale per le attività di calcolo. Di conseguenza, i cloud basati su SAN tendono ad avere prestazioni inferiori a parità di condizioni rispetto ai cloud con soluzioni di archiviazione distribuita locale. Un altro svantaggio di una SAN è che rappresenta un single point of failure molto grande. Le SAN sono estremamente affidabili. Se mai dovessero guastarsi seriamente (e succede), è probabile che vi troviate ad affrontare un'interruzione molto grande e la corruzione dei dati.
La maggior parte dei fornitori di cloud che utilizzano le SAN non impiega soluzioni di fail-over completamente ridondanti del tipo utilizzato in ambiente enterprise, principalmente per motivi di costo. È importante rendersi conto che non tutte le SAN sono uguali e capire, per il fornitore di cloud, quale livello di ridondanza impiegano con le loro SAN.
I cloud basati su archiviazione locale tendono ad avere buone prestazioni del disco. Tuttavia, spesso offrono l'archiviazione locale solo in forma non persistente. Questo non è un confronto equo con l'archiviazione persistente. L'archiviazione temporanea non deve essere robusta ai guasti allo stesso modo dell'archiviazione permanente. È sempre importante confrontare l'archiviazione persistente con l'archiviazione persistente per ottenere risultati significativi.
Quando si esaminano i cloud con soluzioni di archiviazione locale distribuita, è anche necessario sapere quale ridondanza hanno. I dischi rigidi si guastano a un tasso significativo e quindi il metodo di archiviazione è fondamentale. La maggior parte dei fornitori utilizza una qualche forma di RAID ma ci sono livelli di sicurezza molto diversi. All'estremo inferiore si ha il RAID1, in cui due dischi si rispecchiano essenzialmente l'un l'altro. Questo di solito ha buone prestazioni. Ma quando un disco si guasta, finché il disco sostitutivo non copia tutti i dati dal vecchio disco, i dati sono a rischio di perdita totale se il secondo disco (fortemente caricato) si guasta. Inoltre, durante qualsiasi ricostruzione dell'array RAID1, le prestazioni del disco saranno probabilmente molto inferiori al normale.
Molti fornitori, quindi, utilizzano il RAID5 (resistente al guasto di un disco) o il RAID6 (resistente al guasto di due dischi). Il RAID6 offre di gran lunga la soluzione più sicura per l'archiviazione locale, ma comporta una pesante penalizzazione delle prestazioni. Il nostro approccio consiste nell'utilizzare il RAID6 combinandolo con schede controller RAID hardware top di gamma. Dispongono di ampie cache di memoria e sono supportate da batteria. Le schede controller RAID che utilizziamo sono in realtà significativamente più costose dell'intero array di dischi. In questo modo, possiamo offrire prestazioni paragonabili a configurazioni molto meno resilienti, offrendo al contempo la grandissima rete di sicurezza dell'archiviazione RAID6. Scopri di più sulla nostra infrastruttura cloud e sulla sua configurazione, riguardo alla quale siamo molto trasparenti.
Consiglio di utilizzare IOzone o Bonnie++ per i benchmark delle prestazioni del disco.
Quindi, quando si interpretano i risultati dei benchmark di archiviazione, assicurarsi di disporre anche delle seguenti informazioni:
- quale architettura di archiviazione sta utilizzando il cloud (locale, SAN, altro)?
- quali misure di fail-over e ridondanza sono previste per i dati?
- l’archiviazione di cui sto eseguendo il benchmark è temporanea o persistente?
Mettere insieme le risposte a queste tre domande con i risultati del benchmark vi fornirà una discreta comprensione delle prestazioni effettive dell'archiviazione.
Networking
Le prestazioni di rete sono significativamente più semplici da determinare e misurare rispetto alle prestazioni computazionali e del disco. Le prestazioni di rete presentano due aspetti chiave: la latenza e la larghezza di banda.
A seconda delle vostre esigenze, la latenza della rete utilizzata dal fornitore cloud può o meno essere importante. Se utilizzate il cloud per operazioni ampiamente autonome, è improbabile che la latenza sia una priorità. Se invece eseguite applicazioni in tempo reale che interagiscono con il mondo esterno al cloud, la latenza sarà un fattore determinante per le prestazioni.
In genere, la stragrande maggioranza della latenza deriva da una mera distanza fisica. Ad esempio, la maggior parte della latenza tra Londra e San Francisco è in realtà il tempo impiegato dalla luce per coprire tale distanza. Le differenze di latenza sono determinate dalla varia efficienza del percorso intrapreso. Questo è l'aspetto che differisce da cloud a cloud. L'efficienza del percorso è il risultato diretto dei fornitori di rete con cui il cloud ha connessioni dirette. Ciò avviene ottenendo la connettività IP da essi o tramite peering. Quando si analizzano le latenze, è sufficiente eseguire un ping sul server cloud per determinarne le prestazioni. Tuttavia, è importante determinare le prestazioni tra i vostri utenti finali effettivi e il vostro server cloud.
Se la maggior parte dei vostri utenti si trova in un'unica area geografica o se l'accesso avverrà principalmente dalla sede centrale della vostra azienda, è importante testare le prestazioni da tali posizioni. Servizi commerciali come Pingdom offrono un modo conveniente per determinare la latenza da un gran numero di località generali contemporaneamente in tutto il mondo.
L'effettiva larghezza di banda che il vostro server cloud può raggiungere è anch'essa molto importante. A differenza delle soluzioni di hosting più tradizionali, i fornitori di cloud tendono ad addebitare i costi in relazione al volume complessivo di trasferimento dati. In altre parole, non in base al tempo, come nel caso di una tariffazione per Mbit che fornisce un livello fisso di connettività 24 ore su 24, 7 giorni su 7. Nonostante ciò, molti fornitori di cloud applicheranno un ‘throttle’ alla larghezza di banda di qualsiasi server virtuale. Questo sarà invisibile all'utente finché non si raggiunge tale limite. Se avete un profilo di larghezza di banda piuttosto altalenante, questo potrebbe essere un fattore di prestazione importante da prendere in considerazione.
Per testare l'effettiva larghezza di banda del vostro server cloud, è importante provare a scaricare dati sul server cloud da una sorgente che non limiti effettivamente la velocità di trasferimento dal proprio lato. Spesso trovo che un ottimo modo per determinare la velocità disponibile sia scaricare un file di grandi dimensioni da un importante fornitore come Microsoft, Ubuntu o, ancora meglio, aggiornando il sistema operativo. Questo tende a scaricare molti file diversi da varie posizioni contemporaneamente. Vi darà un'ottima idea della velocità della vostra connessione.
Spesso scarico un Fedora live CD dal loro sito principale come test standard, ma dovreste sempre sperimentare almeno con alcuni file e posizioni diverse. Se insistete per avere la vostra rete aziendale velocissima, potreste invece voler scaricare un file dal vostro server cloud sulla vostra rete come test.
Ora aggiungi nuovamente i prezzi per ponderare i risultati
Utilizzando i metodi sopra descritti, dovreste essere in grado di farvi un'idea precisa di come si comportano i vari fornitori di server cloud. Inoltre, dovreste sapere su quali aspetti concentrarvi che sono più importanti per le vostre esigenze specifiche.
L'ultimo passo consiste nell'aggiungere una dimensione di prezzo ai risultati del benchmark. Non esiste una formula per questo. Dipende dalle prestazioni relative dei vari aspetti sopra descritti e sei tu a determinarli. Se un cloud offre prestazioni migliori del 40% (come da te stabilito) ma è solo del 30% più costoso, allora appare chiaramente interessante. Allo stesso modo, se hai una grande necessità di larghezza di banda, prestazioni computazionali inferiori possono essere superate da un piano tariffario competitivo per il trasferimento dei dati. La chiave per prendere la decisione giusta è considerare tutti i vari fattori.
Infine, il benchmarking dovrebbe far parte di un processo più ampio per determinare quali server cloud siano adatti a te. Questo dovrebbe includere altri aspetti. Ad esempio, questi possono includere accordi sul livello del servizio, considerazioni sul vincolo dei dati/fornitore, posizione fisica e giurisdizione legale. Mettendo insieme tutti questi aspetti, sarai in grado di fare la scelta giusta dell’operatore di cloud computing.
Commenti
Ancora nessun commento. Scrivi il primo.