Risultati: test profilo server

Cosa succede se mettiamo insieme 24 SSD DC S3700 Intel, del valore di quasi 50mila euro, e creiamo un gigantesco volume RAID 0? L'apoteosi dell'archiviazione.

Avatar di Tom's Hardware

a cura di Tom's Hardware

Profili carichi di lavoro

Fin da quando hanno iniziato a esistere i programmi per mettere sotto torchio l'attività di I/O, i professionisti hanno cercato di usarli per simulare carichi specifici. Abbiamo preso i nostri SSD DC S3700 per metterli alla prova con alcune operazioni basate su modelli di I/O tipici del mondo enteprise.

Profili
Web Server 100% letture / 0% scritture 0.5 KB 22%, 1 KB 15%, 2 KB 8%, 4 KB 23%, 8 KB 15%, 16 KB 2%, 32 KB 6%, 64 KB 7%, 128 KB 1%, 512 KB 1%
Database 67% letture /

33% scritture

100% 8 KB
MS Exchange Server Emulation 62% letture /

38% scritture

100% 32 KB
File Server 80% letture /

20% scritture

0.5 KB 10%, 1 KB 5%, 2 KB 5%, 4 KB 60%, 8 KB 2%, 16 KB 4%, 32 KB 4%, 64 KB 10%

Profilo Web Server

Il profilo Web server è abbastanza complesso, e consiste di otto differenti dimensioni di trasferimento. Anche se dominano trasferimenti da 0,5 KB, 4 KB e 8 KB, ci sono diverse altre dimensioni nel mix. Questo profilo coinvolge al 100% letture, ma le nostre configurazioni di SSD DC S3700 si comportano quasi allo stesso modo quando si tratta di scritture casuali.

Lo scaling sembra identico a quello che abbiamo visto in precedenza aggiungendo via via le varie unità. Le prestazioni raddoppiano passando da quattro a otto unità, mentre la configurazioni con 24 SSD è un pelo sopra il 100% rispetto a quella con otto SSD.

Profilo database

Il carico di lavoro database è molto semplice. È una dimensione di trasferimento di 8 KB divisa tra il 67% di letture e il 33% di scritture.

La configurazione con 24 unità tocca le 500.000 IOPS. Non è un risultato che ci sorprende, dato che dovremmo vedere la metà quasi esatta delle operazioni di I/O ogni secondo con due volte la dimensione di trasferimento 4 KB. Dato che sia i test in lettura che quelli in scrittura 4 KB arrivano vicino a 1 milione di IOPS, ci attendevamo 500.000 IOPS nel profilo database. Il bandwidth è dato dalle operazioni di I/O al secondo moltiplicate per la dimensione del trasferimento, quindi è essenzialmente stabile in tutti questi test.

Profilo MS Exchange

La maggior parte dei carichi email server più tradizionali sono adeguati. Basta mixare un po' le cose ed emuliamo l'attività mailbox di MS Exchange con blocchi da 32 KB suddivisi tra il 62% di letture e il 38% delle scritture.

Questi sono i primi risultati che non riusciamo a spiegare. Sessione dopo sessione, tocchiamo 200.000 IOPS con 24 SSD. Non è strano, eccetto per il fatto che 200.000 IOPS sono 6.25 GB/s. L'array da 3 TB consiste di quattro SSD DC S3700 che mantengono 40.000 IOPS malgrado la queue depth variabili. Con un throughput di oltre 1200 MB/s, si tratta di risultati totalmente coerenti. Abbiamo raddoppiato quel dato con otto unità e lo abbiamo quadruplicato con 24. Forse abbiamo trovato il perfetto mix d'impostazioni? Poiché il risultato sembra essere troppo bello per essere vero, questi risultati vanno presi con un pizzico di cautela.

Profilo File Server

Il profilo file server è complesso quasi quanto quello Web Server, eccetto per il 20% di transazioni che sono delle scritture e la maggioranza degli accessi che è da 4 KB. Di media, ogni I/O vale approssimativamente 11 KB di throughput.

Lo scaling è ottimale aggiungendo più SSD DC S3700. Da 50.000 IOPS con array di 4 dischi fino a 325.000 IOPS con una configurazione formata da 24 drive, l'aumento prestazionale è lineare con il numero di unità e l'intensità del carico.