Hulp gevraagd voor samenstellen server storage benchmarks

[Femme]

Voor de storage benchmark suite van Tweakers.net wil ik een aantal nieuwe benchmarks maken die het schijfgebruik van een server simuleren. Hiervoor maak ik gebruik van de tools WinTrace32 en RankDisk uit Intel IPEAK Storage Performance Toolkit. Met deze tools kun je traces maken van de schijfbenaderingen in Windows. Die traces kun je vervolgens met RankDisk op een willekeurige schijf of array terugspelen waarna de gemiddelde service time van de I/O operaties als resultaat wordt teruggegeven.

Nu is het natuurlijk erg moeilijk om een representatieve storage benchmark te maken aangezien er enorme verschillen zijn in toepassingen, workloads en datasets. Toch ben ik van mening dat een benchmark die gebaseerd is op traces van een échte (of realistische gesimuleerde) server representatiever is dan een puur synthetische benchmarks zoals bijvoorbeeld IOMeter (waar je alleen kunt aangeven hoe willekeurig een toegangspatroon is, wat de verdeling is van de request groottes en wat de verhouding is tussen lees en schrijf operaties). Wat je in de praktijk vaak zult zien is dat er hotspots op de schijf zijn waar veel data naartoe wordt geschreven, bijvoorbeeld omdat er zich logfiles bevinden. Slimme RAID-adapters kunnen dat goed optimaliseren door schrijfoperaties gecombineerd weg te schrijven. De prestaties in IOMeter zijn daarentegen vooral afhankelijk van de toegangstijd van de schijven en het vermogen van de schijven en de controller om aan command queuing te doen.

Om een redelijk beeld te krijgen van de server prestaties wil ik een trace maken van vijf verschillende scenario's:

- Database-server
- Fileserver
- Mailserver
- 'Workgroup server': combinatie van file-, mail-, proxy-, web- en een simpele database-server op één systeem
- Mediaserver: video- en audiostreaming
- Backupserver

Ideeën voor andere scenario's zijn welkom. Een webserversimulatie laat ik achterwege omdat webservers zelden gebottlenecked worden door disk I/O. Ik heb al enige ervaring opgedaan met het maken van traces voor serverbenchmarks. Daaruit kan ik opmaken dat de belasting in ieder geval behoorlijk hoog moet te zijn om te voorkomen dat bepaalde slimme RAID-adapters onrealistisch goed gaan presteren. Een benchmark waarin een LSI Logic adapter vijf keer snelle is dan een Adaptec vertrouw ik niet helemaal. Niet dat de prestatie van de LSI adapter verkeerd is, maar het is de vraag of dergelijke verhouding zich ook in de werkelijkheid zullen voordoen. Door te zorgen voor grote datasets en een flinke hoeveelheid concurrency zullen intelligente RAID-adapters heb in ieder geval niet gemakkelijk krijgen.

Voor de database server kan ik zelf een simulatie in elkaar sleutelen met de databases van Tweakers.net en GoT. Een backupserver simuleren kan ook niet moeilijk zijn, hoewel ik me wel afvraag hoe dergelijke servers in de praktijk wordt gebruikt. Het gebruik van (ATA-)harde schijven voor backup wordt steeds populairder. Als dergelijke machines 's nachts backups van meerdere servers tegelijkertijd te verwerken krijgen dan is performance belangrijk.

Het probleem is dat ik meer een hardwareman dan een softwareman ben. Enige praktijkervaring met het beheren van servers heb ik niet. De systemen moet realistisch geconfigureerd worden en er moet een workload op gedraaid worden die overeenkomstig de werkelijkheid kan zijn. Het gedrag van users kan gesimuleerd worden met behulp van PHP scripts en apachebench (om hoge concurrency levels te genereren, mav veel gelijktijdige 'gebruikers' of connecties).

Wat ik in dit topic concreet wil vragen is of er mensen zijn die (concrete gedetailleerde) ideeën hebben voor scenario's die gesimuleerd kunnen worden en of iemand binnenkort eens zin heeft om doordeweeks of in het weekend in Amersfoort of in Ruurlo een Windows Server 2003 systeem te configureren met de software die nodig is om het bovenstaande te realiseren (bijv. Exchange). Ik heb een dual Opteron systeem met 2GB RAM en SCSI RAID die als server kan dienen en ik kan beschikken over een gigabit netwerk met zeven pc's (waarvan twee dual processor en vier met gigabit ethernet) die als clients kunnen dienen.

Voor de duidelijkheid: het doel is om disk I/O te genereren dus zo'n server mag grof (en vlug) opgezet worden. Het moet onder Windows draaien vanwege IPEAK Storage Performance Toolkit.

[elevator]

Heb je de standaard tools van Microsoft al eens bekeken in dit geval?
http://www.microsoft.com/...7054595E9C&displaylang=en

en

http://www.microsoft.com/...83C7DDEA85&displaylang=en

[Equator]

Backupservers heb ik er 4 van hangen hier in het rack. Slecht 2 zijn echt operationeel, waarvan er maar 1 is die echt veel doet.

Configuratie:
Compaq Proliant DL380 G3 (Dual Xeon @2,4Ghz 512Kb L2)
1Gb RAM (2 x 512 Synchonous DIMM)
2 x 36,4GB Ultra 3 in een MIRRORSET op een Onboard SmartArray 5i (64Mb Cache)
Tape unit: Compaq MSL5026 met 2 SDLT160/320 Drives.

Netwerk
Extra HP NC7770 Gigabit Server kaart verbonden met een 3Com 2924 GBit Switch

Alle lossen nodes die via deze server gebackupped worden hebben een identieke netwerkkaart verbonden met deze switch.

Wat wil je precies weten van deze configuratie Dan zal ik kijken of ik dat voor je naar boven kan toveren.

EDIT:

Hmm, ik heb net je verhaal iets duidelijk doorgenomen.
Ik kan je iig wel helpen aan een behoorlijke test op je webserver.
Een soort van WebAudit, die met max 32 simultane sessies je webserver (en achterliggende database server) kan proberen onderuit te halen.
Geinteresseerd
Ik wil wel ff komen knustelen hoor

[ Voor 23% gewijzigd door Equator op 01-06-2004 14:40 ]

[Femme]

elevator schreef op 01 juni 2004 @ 13:01:
Heb je de standaard tools van Microsoft al eens bekeken in dit geval?
http://www.microsoft.com/...7054595E9C&displaylang=en

en

http://www.microsoft.com/...83C7DDEA85&displaylang=en

Die laatste tool kan ik goed gebruiken om load te creeëren op een Exchange server.

Alle lossen nodes die via deze server gebackupped worden hebben een identieke netwerkkaart verbonden met deze switch. Wat wil je precies weten van deze configuratie Dan zal ik kijken of ik dat voor je naar boven kan toveren.

Een backuptest zou een systeem moeten simuleren dat backups opslaat op een RAID array (en niet op tape). Dat wordt nog niet zoveel gebruikt maar zal wel populairder worden nu goedkope en grote SATA drives geschikt worden voor servergebruik. De grote jongens zoals EMC hebben al dit soort apparaten. Als zo'n systeem 's nachts backups moet maken van meerdere systemen en die backups gaan door elkaar lopen zal er behoorlijk zware disk I/O ontstaan. Het is dan wel interessant om daar een benchmark voor te bouwen.

Hmm, ik heb net je verhaal iets duidelijk doorgenomen.
Ik kan je iig wel helpen aan een behoorlijke test op je webserver.
Een soort van WebAudit, die met max 32 simultane sessies je webserver (en achterliggende database server) kan proberen onderuit te halen.
Geinteresseerd
Ik wil wel ff komen knustelen hoor

Een database-server (op basis van T.net en GoT databases) stressen kan ik al via wat PHP scripts en apachebench die Tweakers.net/GoT pagina's oproepen op de clients en daarmee load generen op de database-server. Van het inrichten van file- en mailservers heb ik echter geen kaas gegeten. Streaming media ook niet.

[ Voor 3% gewijzigd door Femme op 01-06-2004 14:57 ]

[Equator]

Een database-server (op basis van T.net en GoT databases) stressen kan ik al via wat PHP scripts en apachebench die Tweakers.net/GoT pagina's oproepen op de clients en daarmee load generen op de database-server. Van het inrichten van file- en mailservers heb ik echter geen kaas gegeten. Streaming media ook niet.

De tool die ik gebruik is ook niet echt bedoeld om een database server te laten stressen, maar meer om de webapplicatie te testen op beveiliging.
Hij zal ten alle tijden proberen om je database server tot reacties uit te lokken die niet de bedoeling zijn. Echter kan ik dat met 32 sessies te gelijkertijd.
Ik trok met 16 sessies een databaseserver (MSSQL) van een niet nader te noemen telefoonaanbieder met 2 xeon's op beide processoren tot ruim boven de 80% load.
Het hangt natuurlijk van de databaseinrichting af of dit ook hoge I/O eisen stelt aan de server.

Mailservers (exchange) en fileservers (samba / windows) kan ik je dan misschien wel weer mee helpen. Dat doe ik al enkele jaren.

offtopic:
Als je de tweakers.net frontpage een keer op veiligheid bekeken wil hebben dan kan dat ook hoor.. Mail maar

[elevator]

Femme schreef op 01 juni 2004 @ 14:56:
Een backuptest zou een systeem moeten simuleren dat backups opslaat op een RAID array (en niet op tape). Dat wordt nog niet zoveel gebruikt maar zal wel populairder worden nu goedkope en grote SATA drives geschikt worden voor servergebruik. De grote jongens zoals EMC hebben al dit soort apparaten. Als zo'n systeem 's nachts backups moet maken van meerdere systemen en die backups gaan door elkaar lopen zal er behoorlijk zware disk I/O ontstaan. Het is dan wel interessant om daar een benchmark voor te bouwen.

Ik draai wel met een dergelijk systeem maar daar is weinig verschillende door elkaar lopende IO (eigenlijk strict genomen maar 2 verschillende IO sessies tijdens het backup windows) dus dat zal minder interessant zijn voor een test als de jouwe.

[Verwijderd]

Ik neem aan dat hier ook al gekeken is:

http://www.storageperformance.org/

http://www.acnc.com/benchmarks.html

[ Voor 22% gewijzigd door Verwijderd op 01-06-2004 17:48 ]

[Abom]

Ik heb nu een calamiteiten server ingericht op basis van SATA RAID, en dat is inderdaad rete goedkoop (tov LTO2 tapes).
Ik maak 'real-time' (5 minuten, 25 changes interval per job) backups van onze fileserver. Op dit moment alleen files en nog geen databases. Het 'syncen' van de fileserver doe ik mbv robocopy. Door de gekozen opzet is de server 24/7 bezig is met het synchroniseren van files en niet zoals bij een backup opzet, dat bv 's avonds alles overgooit.

-Nadeel: 24/7 belasting (wel lichte belasting maar je moet er rekening mee houden), robocopy werkt niet met databases
-Voordeel: Je kunt tot 5 minuten voor een calamiteit terug.

Op dit moment zit het allemaal nog in een pilotfase dus ik heb wel de mogelijkheid om een keer een (paar) benchmark(s) te draaien.

[ Voor 6% gewijzigd door Abom op 01-06-2004 23:50 ]

[Arfman]

Ik heb een hele resem W2K servers waar ik dat tooltje wel op kan draaien, roept u maar .. HP NetServer TC4100 met netRAID 2M adapters, DL380 Dual Xeon met SmartArray 5i Plus, ML370 G3 met 6402 controllers, het staat hier allemaal en ik beheer ze
Misschien leuk als vergelijkend materiaal

[reddog33hummer]

Abom schreef op 01 juni 2004 @ 22:35:
Ik heb nu een calamiteiten server ingericht op basis van SATA RAID, en dat is inderdaad rete goedkoop (tov LTO2 tapes).
Ik maak 'real-time' (5 minuten, 25 changes interval per job) backups van onze fileserver. Op dit moment alleen files en nog geen databases. Het 'syncen' van de fileserver doe ik mbv robocopy. Door de gekozen opzet is de server 24/7 bezig is met het synchroniseren van files en niet zoals bij een backup opzet, dat bv 's avonds alles overgooit.

-Nadeel: 24/7 belasting (wel lichte belasting maar je moet er rekening mee houden), robocopy werkt niet met databases
-Voordeel: Je kunt tot 5 minuten voor een calamiteit terug.

Op dit moment zit het allemaal nog in een pilotfase dus ik heb wel de mogelijkheid om een keer een (paar) benchmark(s) te draaien.

Je praat hier over het continu copieren van een server. Dit is alleen niet representatief voor een server in normaal gebruik. Wel voor jouw omgeving maar niet in het algemeen.

Wat we een keer gedaan hebben bij ons op het beheer was dat we 10 gebruikers hebben laten werken en dat op hadden genomen met een soort macro recorder. Dit hebben we toen (in het weekend) af gespeeld (herhalend) op alle client pc's binnen het bedrijf (200 stuks). Dit gaf wel een mooi beeld voor de nieuwe server om te testen of hij het aankon

[Femme]

Verwijderd schreef op 01 juni 2004 @ 17:45:
Ik neem aan dat hier ook al gekeken is:

http://www.storageperformance.org/

http://www.acnc.com/benchmarks.html

Ik maak liever mijn eigen benchmarks. Het voordeel van RankDisk is dat de resultaten erg consistent zijn (afwijkingen van minder dan een halve procent zijn normaal) en dat het weinig interventie van de gebruiker nodig heeft.

Om een goede benchmark te kunnen maken moet ik een realistische simulatie opzetten met workloads die in de praktijk kunnen voorkomen. Omdat zelf een praktijkervaring heb met het inrichten van mailservers en fileservers lijkt het mij het beste om het inrichten van de server en de simulatie aan iemand over te laten die wel (professionele) ervaring heeft.

[SnowDude]

Wil je eigenlijk ook rekening gaan houden met de verschillende file systems? Er zit wel degelijk een verschil tussen, een NetWare server met een NSS3 partitie en een W2K(3) machine met NTFS

[Femme]

Uiteindelijk wil ik de prestaties meten van de hardware (harde schijven en/of I/O controllers). Het is de vraag of er structurele verschillen zijn in prestaties van verschillende harde schijven en I/O controllers onder verschillende bestandssystemen als de workload gelijk is.

Ik kan er verder ook niet veel meer omdat IPEAK Storage Performance Toolkit alleen onder Windows draait en er geen alternatief voor IPEAK SPT is.

[SnowDude]

Eigenlijk heb je ook wel gelijk, de performance verschillen tussen bijvoorbeeld een Seagate en een IBM disk zullen bij alle file systems wel ongeveer gelijk zijn.

[klaasbaas]

Je vraagt om scenarios; bij deze een scenario uit de praktijk van mijn kleine bedrijfje. Welliswaar niet op een windows-server, maar wellicht toch nuttig.

Vanaf 4 locaties (3 via inet, 1 lokaal) worden 's nachts synchronisaties uitgevoerd naar de backup-server. Overdag maakt deze dagelijks een incrementele backup naar een tweede disk (in jouw geval een array) en wekelijks een full backup.

Hiermee kan ik voor deze bestanden dus 1,2,3,4,5,6,7,14,21,... dagen terug in de tijd. Het gaat hier enkel om bestanden, niet om databases.

Doel hiervan is op een voordelige wijze een remotebackup als aanvulling op de lokale backups te creëeren.

Off topic: bovengenoemde contructie werkt erg goed, maar ik sta open voor commentaar of suggesties.

[elevator]

SnowDude schreef op 02 juni 2004 @ 15:15:
Wil je eigenlijk ook rekening gaan houden met de verschillende file systems? Er zit wel degelijk een verschil tussen, een NetWare server met een NSS3 partitie en een W2K(3) machine met NTFS

De meeste testen waar het hier over gaat is het wegschrijven gefixeerd op een paar grote files (een grote backup-file, of een grote datbase met wat logs) - ik vermoed dan ook dat het filesystem in dit niet zo heel veel uit zal maken.

Wil je echter pure fileserver performance testen waarin je naar het miljoen files toe gaat dan denk ik dat je filesysteem wel degelijk een bottleneck kan worden voor je performance testen.

[Equator]

elevator schreef op 04 juni 2004 @ 13:24:
[...]

De meeste testen waar het hier over gaat is het wegschrijven gefixeerd op een paar grote files (een grote backup-file, of een grote datbase met wat logs) - ik vermoed dan ook dat het filesystem in dit niet zo heel veel uit zal maken.

Wil je echter pure fileserver performance testen waarin je naar het miljoen files toe gaat dan denk ik dat je filesysteem wel degelijk een bottleneck kan worden voor je performance testen.

toch als je hele grote bestanden hebt, die je moet verplaatsen of op disk schrijven, dan is een grotere cluster grootte binnen je NTFS wel degelijk gunstig.

Op sommige scsi raid controllers (HSZ, HSG controllers) kan je ook nog wat qua block zsize instellen. Dit is dan wel hardware, en heeft niet met FileSystem te maken)

[elevator]

CyberJ schreef op 04 juni 2004 @ 14:06:
toch als je hele grote bestanden hebt, die je moet verplaatsen of op disk schrijven, dan is een grotere cluster grootte binnen je NTFS wel degelijk gunstig.

Ik heb dat nog nooit echt getest - ik weet dat het wat uitmaakt voor je pagefile (bv. op een Citrix server), maar voor andere doeleinden (Exchange DB / logfiles of een MSSQL DB) heb ik persoonlijk nog geen performance verschil kunnen merken in de (overigens zeer oppervlakkige) testjes die ik er ooit mee gedaan hebt.

[SnowDude]

CyberJ schreef op 04 juni 2004 @ 14:06:
[...]
toch als je hele grote bestanden hebt, die je moet verplaatsen of op disk schrijven, dan is een grotere cluster grootte binnen je NTFS wel degelijk gunstig.

Op sommige scsi raid controllers (HSZ, HSG controllers) kan je ook nog wat qua block zsize instellen. Dit is dan wel hardware, en heeft niet met FileSystem te maken)

Op de meeste raid controlers die je in de grote servers vind kan je de block en stripe size instellen, iets waar heel veel mensen overheen kijken, Als je blocksize op de controler niet overeen komt met de blocksize van je file system kost dat performance.

@ elevator: ik had mij zelf al verbeterd, twee posts later

[Femme]

De simulatie van een Exchange mailserver kan hopelijk opgelost worden met die LoadSim tool van Microsoft.

Voor de fileserver tests dacht ik aan drie scenario's met verschillende soorten files: een fileserver die kleine files serveert (bijv. Word-documenten), een server die redelijke grote files doet (PDF documenten) en eentje die gebruikt wordt in een multimedia studio waar zeer grote files (grafische documenten, video en audio) op een server worden opgeslagen.

Heeft iemand enige ervaring met verhouding lees/schrijf I/O in deze drie scenario's? (dat zal natuurlijk per bedrijf anders zijn maar ik wil een grof gemiddelde).

Wat me verder een goede toevoeging lijkt is het benchmarken van de performance in bepaalde I/O intensieve taken zoals een virusscan of een backup, dus een fileserver simulatie doen en tegelijkertijd een backup of virusscan draaien. Het lijkt me belangrijk dat een server in dit soort situaties voldoende performance blijft bieden.

CyberJ schreef op 04 juni 2004 @ 14:06:
[...]

Op sommige scsi raid controllers (HSZ, HSG controllers) kan je ook nog wat qua block zsize instellen. Dit is dan wel hardware, en heeft niet met FileSystem te maken)

Mijn ervaring is dat de stripe size een grote invloed kan hebben op de prestaties. Als ik RAID adapters ga benchmarken zoek ik eerst uit welke stripe size het beste presteert op de specifieke adapter. Tot nu toe heb ik de traces gemaakt met de default NTFS block size van 4KB (?). De meeste adapters presteren optimaal bij 128K of 256K stripe size (als het aantal schijven niet erg groot is) in de desktop tests en 64K of 128K in de server tests.

[elevator]

Femme schreef op 04 juni 2004 @ 14:47:
Heeft iemand enige ervaring met verhouding lees/schrijf I/O in deze drie scenario's? (dat zal natuurlijk per bedrijf anders zijn maar ik wil een grof gemiddelde).

Hoe zou je dit willen meten?
Denk je evt. aan iets als dit:

code:

\\xxx01 has been up for: 146 day(s), 21 hour(s), 7 minute(s), 33 second(s)
File System Type :     NTFS

UserFileReads :        295569929
UserFileReadBytes :    1200144384
UserDiskReads :        296911492
UserFileWrites :       27509404
UserFileWriteBytes :   3565849600
UserDiskWrites :       24723303
MetaDataReads :        76494496
MetaDataReadBytes :    4083810304
MetaDataDiskReads :    112325400
MetaDataWrites :       68387296
MetaDataWriteBytes :   3615592448
MetaDataDiskWrites :   92029408

MftReads :             75594798
MftReadBytes :         4693614592
MftWrites :            62078851
MftWriteBytes :        1833254912
Mft2Writes :           0
Mft2WriteBytes :       0
RootIndexReads :       0
RootIndexReadBytes :   0
RootIndexWrites :      0
RootIndexWriteBytes :  0
BitmapReads :          128583
BitmapReadBytes :      526675968
BitmapWrites :         5377360
BitmapWriteBytes :     3383672832
MftBitmapReads :       3291
MftBitmapReadBytes :   13479936
MftBitmapWrites :      835057
MftBitmapWriteBytes :  6575820800
UserIndexReads :       35831032
UserIndexReadBytes :   5029986304
UserIndexWrites :      15858561
UserIndexWriteBytes :  2490257408
LogFileReads :         6
LogFileReadBytes :     24576
LogFileWrites :        11253364
LogFileWriteBytes :    6680379392

Wat een dump is van fsutil ntfsinfo statistics op één node van een file/print cluster ? (ik weet niet in welke fase / ofdat de statistieken hiervan "overwrappen" - dus de statistieken kunnen ook volledig fout zijn )

Wat me verder een goede toevoeging lijkt is het benchmarken van de performance in bepaalde I/O intensieve taken zoals een virusscan of een backup, dus een fileserver simulatie doen en tegelijkertijd een backup of virusscan draaien. Het lijkt me belangrijk dat een server in dit soort situaties voldoende performance blijft bieden.

Wij hebben er voor gekozen de servers niet in die extreme te schalen en hebben daarom ook backups die buiten de standaard werkuren vallen draaien. Vermoedelijk doen veel bedrijven dit omdat een 100% normale belasting + backup belasting een server best veel belast.

Mijn ervaring is dat de stripe size een grote invloed kan hebben op de prestaties. Als ik RAID adapters ga benchmarken zoek ik eerst uit welke stripe size het beste presteert op de specifieke adapter. Tot nu toe heb ik de traces gemaakt met de default NTFS block size van 4KB (?)

Afhankelijk van hoe je formatteert verschilt de 'standaard' clustersize van NTFS nogal - (2003/XP: fsutil ntfsinfo c: om het op te vragen - als je op 2000 dit wil checken kan je fsutil copieeren van een XP machine zoals ik hierboven ook gedaan heb).

De meeste adapters presteren optimaal bij 128K of 256K stripe size (als het aantal schijven niet erg groot is) in de desktop tests en 64K of 128K in de server tests.

Wat is een groot aantal schijven?

[ Voor 3% gewijzigd door elevator op 04-06-2004 20:15 ]

[reddog33hummer]

Afhankelijk van hoe je formatteert verschilt de 'standaard' clustersize van NTFS nogal - (2003/XP: fsutil ntfsinfo c: om het op te vragen -

(*kuch) fsutil fsinfo ntfsinfo C: (*kuch)

[ Voor 18% gewijzigd door reddog33hummer op 07-06-2004 18:15 ]