File server en I/O performance - van 10K RPM naar 7200RPM?

[Q]

Hallo,

Ik heb een file server (virtueel) onder beheer die op 10K RPM schijven draait. Dat ding staat met 150 gebruikers eigenlijk de hele dag uit zijn neus te vreten, is mijn indruk op basis van wat metingen met vscsistat / esxtop etc.

Ik zou liever al die 10K RPM disks vrij maken en de file server op een stuk of 10 x 1 TB @ 7200 RPM disks willen gooien in RAID6. Ik kan dan een stuk leukere dingen doen met die 10K RPM schijven.

Het belangrijkste risico is de reductie in het aantal spindels en dus het aantal IOPS, met name random IOPS. Ik vermoed echter dat file server access meestal niet zo random is en goed gecached kan worden door de file server.

Zijn er een beetje goede vuistregels wat dit betreft voor het dimensioneren van een file server? Het gaat hier om 5 TB aan data.

[Paul]

Nu ja, je weet hoeveel IOPS je gebruikers doen, je weet hoeveel je 10K schijven kunnen en hoeveel 7k2-schijven kunnen, dan wordt het mijns inziens redelijk simpel:

if IOPS_MAX(current+growth) < IOPS_MAX(7k2) then diskarray.replaceDrives();

Oftewel, zoek uit wat je IOPS zijn, overleg met de leverancier van je diskarray wat de specs zijn bij diverse set-ups en kijk of je daarmee uit komt

[Q]

IOPS MAX zegt niet zoveel omdat je heel veel IOPS krijgt als je gewoon sequentieel data benadert.
Je weet niet of die IOPS random of sequentieel zijn. Of een mix (waarschijnlijk).

[Paul]

Daarom gaan we over het algemeen uit van de worst-case scenario: random Pas als je kunt onderbouwen hoeveel ervan sequentieel is kun je dat meenemen in je berekening.

Vergis je trouwens niet hoeveel random IO die 150 users kunnen genereren. 1 gebruiker leest waarschijnlijk wel een heel bestand, maar de ander 149 gebruikers lezen ieder een ander bestand. Nu is niet iedereen constant (op de schijf) bezig, maar toch krijg je regelmatig meerdere verzoeken tegelijk.

[Q]

Ik vermoed dat het gedrag op de file server vanuit de storage gezien daarom ook random is en dat de file server ook hot spots zal kennen. Dat is echter niet zo'n punt omdat de data toch gestriped wordt over een stuk of 8 spindels.

[Paul]

...maar daarom kun je dus wel rekenen met deze KPI's Zie bijvoorbeeld http://www.techrepublic.c...s-in-a-storage-array/2182

Als een 10K-spindel 100 IOPS doet en je 8 spindels in RAID10 hebt dan heb je dus bij schrijven een IOPS_MAX van 400 en bij lezen 800.

Doet een 7K2-spindel 72 IOPS dan doen je 10 spindels in RAID6 dus 720 IOPS_MAX bij lezen en 120 bij schrijven.

[Q]

Precies en met name die worst-case IOPS write performance is eng, maar hoeveel wordt er afgevangen door caching dus hoeveel last heb je daar echt van......

Van die 10 x 7200 RPM in RAID 6 benut je er maar acht. Bij zeg 72 iops per disk is dat 567 read en slechts 96 voor de writes. Dat is dus ~ 4 read iops per user en ~ 0,6 write iops per user.

Dat klinkt niet echt lekker. Zelfs al werken er maar 75 continue op hun computer. Lastig. sec op deze rekensom zou je het niet moeten doen zeker niet als je groter schaalt naar meer gebruikers.

Je kunt gewoon meer spindels toevoegen en de extra storage niet gebruiken of zelfs onder partitioneren maar waar ben je dan mee bezig, vraag ik me hard op af.

Een worst-case scenario is niet realistisch maar je moet ook niet te lichtzinnig zijn. Eigenlijk wil je een soort random IOPS per user vuistregel zoeken van een betrouwbare bron om een schatting te kunnen maken. Anders moet je eigenlijk je eigen storage gebruik gaan profilen en hoe bepaal je 'hoe random' het gedrag is?

Ik ga wel eens uitzoeken hoeveel % van de reads/writes door de cache worden afgevangen, maar ook daarvoor geldt, dan weet je dat, en dan?

[ Voor 24% gewijzigd door Q op 27-11-2012 18:57 ]

[Paul]

Bij lezen gebruik je alsnog alle schijven, de data staat op alle schijven verdeeld, het is niet zo dat 2 fysieke schijven dedicated zijn voor de parity

Als je weet hoeveel er door caching wordt afgevangen krijg je dus hogere (met name write) IOPS en kun je dus inschatten hoeveel schijven je nodig denkt te hebben.

"Dat klinkt niet echt lekker, ook al zit maar x% achter hun computer" klinkt alsof je niet weet hoeveel IOPS je users nu nodig hebben? Als ik naar mijn eigen gebruik kijk (af en toe een Word- of Excel-bestand opslaan [autosaves gaan naar %temp%, niet naar je fileserver] maar wel redelijk wat Word-, Excel- en PDF-bestanden bekijken) dan is het leeuwendeel ervan lezen en maar weinig schrijven.

De Tweakers Benchmark gaat ook uit van 80% lezen.

[Q]

Ik weet dat met RAID 6 de parity over de disks verdeeld wordt maar het principe blijft: je offert 2 disks aan capaciteit op voor parity dus effectief heb je maar 10-2 = 8 disks die mee doen met lezen. Niet alle disks dus, voor zover ik weet.

Het probleem is zich eigenlijk aan het oplossen. Het blijkt dat het uiteindelijk via onze leverancier niet heel veel duurder is om wat meer 600 GB 10K schijven te kopen dan een kleiner aantal 1 TB schijven. Het enige nadeel is dat je er meer nodig hebt.

[hans_lenze]

Stel dat een bestand uit tien blokken bestaat. De leesopdracht van
block1 benadert dan disk 0 - 7
block2 benadert dan disk 2 - 9
block3 benadert dan disk 4 - 2
enz

Op welk moment doen er maar acht schijven mee? Op het moment dat elke gebruiker exact dat ene blokje wil hebben dat alleen maar op die acht schijven staat. Kans daarop is nihil als je een minuut meet.

[Q]

Ik zit fout, ik snap het nu beter. Juist omdat de parity over de disks verdeeld wordt doen alle disks mee in het lees verhaal.

Mijn denk fout was dat ik mij beperkte tot 1 stripe read. Maar als je een hele file inleest, die over meerdere stripes lopen, dan doen effectief alle disks mee.

[Powermage]

De vraag word nu ook vrij dramatisch vergeleken.
een Paul haalt een Raid 10 aan van 8 spindels@10k tegenover een Raid6 met 10 spindels @7,2K
dat is natuurlijk een behoorlijk verschil.

Even simpel lomp gezegd, draai je nu op een Raid10 @10K ga je zeker verschil merken met een Raid6 met langzamere disken, een goede controller vangt wel eea op, maar niet zo ver.

Draai je nu al een Raid6 met 10K disken is je verschil vele malen kleiner en wanneer die server echt ""de hele dag uit zijn neus te vreten" zal je dit vermoedelijk niet gaan merken.

[Paul]

Hmm, geen idee waar ik die RAID 10 vandaan heb Denk van de 10K RPM of zo

[Q]

Het ging om RAID6.

Om 'redenen' staat de data nu op 2x16 = 24 x 10K 450GB schijven. Nogal duur voor een file server, vind ik dan. Met name het aantal spindels. En we hebben hard wat extra spindels nodig want een array met allemaal VMs trekt het niet meer.

Ik wil die spindels dus vrij spelen om daar iets nuttigers mee te doen. Door de data naar grotere 10K schijven te migreren bespaar je spindels. De verloren IOPS zijn geen issue.

Maar we hebben een aardige deal met 600GB 10K schijven dus die 7200RPM zijn uit de picture.

Met de 25 vrij gespeelde spindels kun je een aantal leuke RAID 10 en RAID 5/6 arrays maken voor VMs met verschillende performance behoeften en high-io VMs op separate arrays zetten zodat ze elkaar niet in de weg zitten.

[ Voor 27% gewijzigd door Q op 01-12-2012 12:25 ]