![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
Voltooiing StorageMark 2004 suite (2)
Om dichter in de buurt van de waarheid te komen, moesten er dus workloads van 'echte' servers gesimuleerd worden. De hiervoor benodigde tools waren al beschikbaar: met Intel IPEAK Storage Performance Toolkit, een prachtig stuk gereedschap waarvan de ondersteuning helaas door Intel is stopgezet, is het mogelijk om traces van schijfbenaderingen vast te leggen en later op elke willekeurige fysieke schijf terug te spelen. Deze methode gebruikten we al voor desktop benchmarks in de StorageMark 2003 en 2004 suites. Om een breed en zo betrouwbaar mogelijk beeld te kunnen geven van de serverprestaties werden er traces gemaakt van een disk-to-disk backupserver, fileserver, database-server, streaming media server en een mailserver. Per toepassing werden minimaal twee scenario's gemaakt die verschilden in de grootte van de dataset, het aantal gelijktijdige connecties of de distributie van de bestandsgrootte.
Omdat de benchmarks gebruikt zullen worden voor het testen van zeer uiteenlopende storage subsystemen was het uitermate belangrijk dat de benchmarks schaalbaar werden. De benchmarks moeten net zo goed bruikbaar zijn voor het testen van alleenstaande SATA-harde schijven als voor het benchen van grote SCSI RAID arrays. Benchmarks met een te kleine dataset kunnen belachelijk goed presteren op zware intelligente RAID-adapters en als er sprake is van een te lage concurrency zullen de prestaties nauwelijks schalen op grote arrays. Om dit te probleem te ondervangen moest een zeer snelle server als uitgangspunt genomen worden voor de traces. Door vervolgens per servertype verschillende scenario's te simuleren konden we de workloads van grote, middelgrote en kleine servers vastleggen.
Omdat de benchmarks gebruikt zullen worden voor het testen van zeer uiteenlopende storage subsystemen was het uitermate belangrijk dat de benchmarks schaalbaar werden. De benchmarks moeten net zo goed bruikbaar zijn voor het testen van alleenstaande SATA-harde schijven als voor het benchen van grote SCSI RAID arrays. Benchmarks met een te kleine dataset kunnen belachelijk goed presteren op zware intelligente RAID-adapters en als er sprake is van een te lage concurrency zullen de prestaties nauwelijks schalen op grote arrays. Om dit te probleem te ondervangen moest een zeer snelle server als uitgangspunt genomen worden voor de traces. Door vervolgens per servertype verschillende scenario's te simuleren konden we de workloads van grote, middelgrote en kleine servers vastleggen.
Rechts van de KVM LCD switch de server waarop de traces werden gemaakt
Gelukkig was het geen probleem om toegang te krijgen tot zware hardware voor de simulatieserver. Ten kantore stond reeds een gloednieuwe dual Opteron 244 met 8GB RAM, acht SCSI-harde schijven (twee keer 10K en zes keer 15K) en een LSI MegaRAID SCSI 320-2X met 512MB cache in de startblokken om de database-server van het forum te vervangen. Betere spullen voor het maken van de server traces konden we ons niet wensen. Onder systeembeheerders in de GoT crew werd advies gevraagd voor de samenstelling van de workloads, die vervolgens werden gesimuleerd met een verzameling zelfgemaakte PHP scripts en load simulatie tools van Microsoft. Voor de database-simulatie maakten we gebruik van de databases van Tweakers.net en GoT, die bij elkaar enkele tientallen gigabytes groot zijn. Bijzondere dank zijn we verschuldigd aan GoT-veteraan Arno Bottema, die als ervaren Exchange administrator verantwoordelijk was voor de Exchange 2003-simulaties.
We zijn ons er overigens ter dege van bewust dat de workloads van serversystemen enorm uiteenlopend zijn. Toch zijn we ervan overtuigd dat we met de nieuwe set benchmarks aanzienlijk realistischer prestatiemetingen kunnen doen dan met de zeer beperkte IOMeter serversimulaties.
Volgende pagina (Western Digital Media Center - 4/8)
