2013-07-03 15 views
6

Ho sviluppato un sistema di archiviazione cloud che utilizza la stessa struttura API di Amazon S3. Ora voglio eseguire alcuni test delle prestazioni su ottenendo dati oggetto e metadati oggetto. In questo modo posso confrontare il mio sistema con Amazon S3, lo storage OpenStack e altri sistemi.Come eseguire il benchmark dei sistemi di archiviazione cloud come Amazon S3

Ho esaminato alcuni strumenti di benchmark di file system comuni, c'è troppo lavoro per convertirli per i sistemi di cloud storage.

Sono alla ricerca di alcuni strumenti di riferimento simili a SIEGE, che non solo possono richiedere le richieste HTTP, ma hanno anche alcune funzioni di simulazione del carico di lavoro. Ad esempio, una simulazione può memorizzare un intero sito Web HTML statico nel Cloud Storage, quindi eseguire alcuni stress test del carico di lavoro ecc.

Qualcuno può aiutare e suggerire alcuni framework o strumenti esistenti che possono essere relativamente facili da installare per tale cloud scenario di riferimento del sistema di storage?

+0

Nota che S3 è un sistema dinamico, quindi fare un "benchmark rapido" ti darà numeri terribili. Ecco un articolo su un test simile eseguito su ELB: http://www.rightscale.com/blog/cloud-management-best-practices/benchmarking-load-balancers-cloud – BraveNewCurrency

risposta

2

Come fornitore del sistema cloud. Ci sono molti aspetti da valutare.

come fornitore

  • availbility del servizio, la ridondanza.
  • bandwith nel tempo, io/s nel tempo.
  • frammentazione della soluzione di archiviazione.
  • responsabilità/ripristino/failover a guasti meccanici/elettrici.
  • cache predefinita & cache di overflow 'massiccia accesso casuale' o 'accesso seriale'

Per tutti thoses cose c'è specifics strumenti/api/controlli. A volte è strettamente correlato al tuo hardware, a volte meno. Ma il collegamento tra l'hardware e il software si traduce in misure specifiche e problemi di integrazione. Definire cosa sia un benchmark o effettuare il routing di una query 'end-to-end' da 'objet storage api' ai dischi può essere semplicemente follemente difficile. Se il tuo obiettivo è quello di ottenere un punto di riferimento (in un livello più alto di API) che potrebbe finire per migliorare il tuo sistema, allora la tua unica soluzione è avere un controllo totale (e comprensione) del tuo sistema cloud;

Nagios come strumenti, non sono adatti per questo tipo di test. Avete bisogno di CMDB e di alcuni strumenti di recupero in una grande archiviazione orientata ai dati. Devi capire che tutte le soluzioni di benchmark sono dati primari e dato che il cloud può essere molto complesso, ci sono molti dati. Quello che imparerai dai tuoi dati non sono solo alcuni dati grafici, ma anche alcuni come porre le tue domande. Anche ottenere le domande sui diritti ti chiederà di lavorare.

Come ho detto nella mia prima risposta breve usiamo VMware VMmark per condurre questo tipo di test, ma solo una piccola parte. C'è un numero così grande di strumenti (giusto per fare un monitoraggio in tempo reale - benchmarking che) che una persona non può conoscerli tutti. A lavoro, sto facendo alcuni prog AI (rete bayesiana per il rilevamento dei guasti, algoritmi evolutivi per la riparazione ...) per consentire una migliore gestione di quelle cose.

Solo per stuzzicarti: ti aspetti di condurre un benchmark quando installi un nuovo cliente, scambia lo spazio di altri due ed esegui il piano di emergenza di un ultimo, tutto nello stesso tempo?

Un punto di riferimento corretto dovrebbe coprire così tanti casi. Oggi il cloud deve gestire la complessità del mondo, ogni evento caotico; niente dovrebbe distrarre il servizio. Quindi, solo per dire che cosa è un punto di riferimento è piuttosto difficile.

(che alimenta il CMDB è di per sé una sfida)

come client

sì :-) Sono anche cliente di fornitori di cloud, come ogni essere umano farà nel prossimo futuro. Solo un po 'di background. Openstack è stato inizialmente rilasciato da organizzazioni con esigenze molto specifiche (basti pensare che, nella parte 'Compute' della API 'openstack' non c'è nulla di correlato all'elaborazione share/cluster che assomiglia a ciò che consuma lhc). Allora, qual è un normale sito web? Youtube ? Amazon? Anche se è solo per un esempio, un "intero sito Web HTML statico" potrebbe difficilmente essere utilizzato per confrontare la soluzione cloud.

Questa settimana ho anche lavorato sulla traduzione di vCloud api in openstack (gioco libero), vCloud è ben definito, con più oggetti che aprono, ma anche con questo copriamo così poche esigenze di applicazioni gestione.

Quindi, come il cliente può confrontare due soluzioni cloud? Infatti, prima di provare la propria soluzione, non può. Questo è il motivo per cui i clienti, vengono a trovarci, chiedono che cosa stiamo usando e come, il nostro processo ... Alla fine gli annunci pubblicitari per il lavoro, in genere pochi mesi senza addebiti solo per installare il client e trovare quello che dovremmo fare per riconfigurare il nostro cloud alle sue applicazioni. Pochissimi clienti sanno quanti cpu/ram/disk/iops usano; alcuni di loro acquistano risorse dedicate (dato che è impegnata non possiamo condividere con altri clienti) che non useranno mai.

Quindi qualsiasi strumento di benchmark per il normale sito web dovrebbe fare il lavoro. Se vuoi giocare puoi aprire strumenti 'interni' come swiftstack e tempest per ottenere una sorta di feedback, ma devi definire che aspetto dovrebbe avere un normale utilizzo di un sito web. Se cerchi i prodotti openstack correlati dovresti dare un'occhiata anche allo wiki. Ma se vuoi solo più di A è più veloce di B è la condizione che imposti, sarà quasi impossibile come cliente.

Credo di aver spiegato perché nessun "cliente" ha risposto alla tua domanda fino ad ora, mentre la tua domanda è di vitale importanza in molti aspetti commerciali/industriali/ecologici.

1

Probabilmente è possibile esaminare COSBench, che è uno strumento per il benchmark dei servizi cloud di archiviazione degli oggetti.

Problemi correlati