Jump to content
Melde dich an, um diesen Inhalt zu abonnieren  
magicpeter

StarWind Virtual SAN - Welche Erfahrungen habt Ihr mit Produkt?

Empfohlene Beiträge

Was zum Vergleich, Daten die ich vor 2 Jahren mit einem alten Fujitsu SAN und einem IBMDS3500 gemessen habe, beide RAID5. Fujitsu SAN hat 12x 1TB 7,2 Umdrehungen 3,5". IBM SAN hat 24x 900GB 10.000 Umdrehungen SAS. Beide haben Dual-Controller 1GBe Multipath und Cache 1-2 GB auf dem Controller.

 

Test 1: IOMeter - All-in-One – laut einfachem Guide
 
Fujitsu Fibrecat
 
Total I/Os per Second: 4111.25
Total MBs per Second: 52,69
Average I/O Response Time ms: 2,6747
Maximum I/O Response Time ms: 345,0327
% CPU utilization total:  15,09%
 
IBM DS3500
 
Total I/Os per Second: 7634,98
Total MBs per Second:  97,87
Average I/O Response Time ms: 1,4398
Maximum I/O Response Time ms: 521,0161
% CPU utilization total:  23,51%
 
Fazit: Das IBM SAN ist bei diesem Test so ca. 85% schneller als das Fujitsu SAN. Dies sowohl in IOps als auch in MB/s.
 
Test2: Microsoft Exchange 2010 Jetstress 2010 (64bit) - Performance Test
 
Fujitsu Fibrecat: IO/s 247,982
IBM: IO/s 1836,921

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

 

Was zum Vergleich, Daten die ich vor 2 Jahren mit einem alten Fujitsu SAN und einem IBMDS3500 gemessen habe, beide RAID5. Fujitsu SAN hat 12x 1TB 7,2 Umdrehungen 3,5". IBM SAN hat 24x 900GB 10.000 Umdrehungen SAS. Beide haben Dual-Controller 1GBe Multipath und Cache 1-2 GB auf dem Controller.

 

Moin,

ich gehe mal davon aus, dass es sich bei den Platten im Fujitsu SAN um NL-SAS gehandelt hat.

Insgesamt kann an den Werten ganz gut den Performance-Unterschied zwischen echten SAS und NL-SAS ablesen. Man muss natürlich dabei beachten, dass das IBM SAN doppelt so viele Spindeln hatte wie dass Fujitsu SAN.

Inwieweit solche Benchmarks generell vergleichbar sind lasse ich mal außen vor. Aber eine Tendenz ist zumindest gut erkennbar.

 

Gruß

Dirk

bearbeitet von monstermania

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hi,

 
Ich habe das Testsystem noch etwas mit einer SSD Samsung 850 EVO mit 250 GB erweitert.
 
Hier meine neuen Testergebnisse:
 
Testsoftware:
 
IOMETER.
Version
2006.07.27
 
Test-Pattern: AllinOne
Max Size: 8000000 Sektoren
Test-Dauer: 60 Minuten
 
Hardware:
 
Server:
Supermicro
RAM: 64 GB
CPU: 2 x E5-2620 - 2 GHz
Raidcontroller: LSI-9750-4i
HDD: WD VelociRaptor 1 TB 10k
SSD: Samsung 850 EVO 250 GB
Volume0: System - 2 x HDD - Raid 1
Volume1: Daten - 2 x HDD - Volume E - Raid 1
Volume2: StarWind LSFS Volume H - Volumen auf Volume E mit Ram 1L Cache
Volume3: StarWind LSFS Volume I - Volumen auf Volume E mit RAM 1L Cache 1024 MB und SSD 2L Cache 1024 MB
 
Software:
 
Windows 2012 Standard
StarWind Virtual SAN 8.0
 
 
Transferraten:
 
Volume1: Daten - 2 x HDD - Volume E - Raid 1
 
IOPS = 144
Average Response Time = 6.899497
Average Read Response Time = 8.601612
Average Write Response Time = 0.225388
 
 
Volume2: StarWind LSFS Volume H - Volumen auf Volume E
Thin Provisioned LSFS
 
IOPS = 549
Average Response Time = 1.817441
Average Read Response Time = 2.223474
Average Write Response Time = 0.175550
 
 
Volume3: StarWind LSFS Volume I - Volumen auf Volume E mit RAM 1L Cache 1024 MB und SSD 2L Cache 1024 MB
Thin Provisioned LSFS mit In-Line Deduplication und Compression
 
IOPS = 2336
Average Response Time = 0.426799
Average Read Response Time = 0.454190
Average Write Response Time = 0.399883
Total MBs per Second: 29.92
% CPU utilization total:  4.77 %
 
Also 2336 IOPS mit einem Raid1 ist jetzt so schlecht nicht oder?
Ich denke das ist für eine kleine Virtualisierungsumgebung bei KMUs eine interessante Alternative.
Sollte man einmal im Hinterkopf behalten.
bearbeitet von magicpeter

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin Peter,

sorry, aber da bewegst Du Dich auf einem ganz schmalen Brett. ;)

Deine Messwerte sind sicherlich richtig. Aber ich gehe mal davon aus, dass Dein Benchmark überwiegend im SSD-Cache abläuft bzw. im Cache von Starwind abläuft. Daher die guten IOPS. Das mag unter Praxisbedingungen dann aber gaaanz anders aussehen! Mehr als die 144 IOPS von Volume 1 gebe ich dem System nicht!

 

Dass ist eben genau das Problem mit Benchmarks. Sie spiegeln nicht die Praxis wieder!

 

Gruß

Dirk

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

lass mal 10 oder mehr Worker mit unterschiedlicher Konfiguration (Varianten: read/write, sequenziell, random, blocksize) auf zwei oder mehr Systemen parallel laufen.

Im Idealfall hast Du ein Muster aus der Praxis, das Du in IOMeter nachstellen kannst. Dann gibt es repräsentative Werte.

 

Moin Peter,

sorry, aber da bewegst Du Dich auf einem ganz schmalen Brett. ;)

Deine Messwerte sind sicherlich richtig. Aber ich gehe mal davon aus, dass Dein Benchmark überwiegend im SSD-Cache abläuft bzw. im Cache von Starwind abläuft. Daher die guten IOPS. Das mag unter Praxisbedingungen dann aber gaaanz anders aussehen! Mehr als die 144 IOPS von Volume 1 gebe ich dem System nicht!

 

Dass ist eben genau das Problem mit Benchmarks. Sie spiegeln nicht die Praxis wieder!

 

Gruß

Dirk

Sieht verdächtig danach aus

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Du solltest dich eher an den realistischen 144 IOPS orientieren. Wie von Dunkelmann erwähnt hast du 99% im Cache abgefackelt und da kommen dann Traumwerte raus.

Vielleicht solltest du mal 4-5 Threads von IOMeter gleichzeitig starten mit verschiedenen Workloads.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
Melde dich an, um diesen Inhalt zu abonnieren  

×