SCSI Stripe / mirror snelheidberekening

[Verwijderd]

weet iemand of er een tooltje beschikbaar is om te bereken hoe snel een stripeset gaat worden?

ik wil hier de diskcapaciteit gaan uitbreiden.

Nu hebben een 8 x 73.4Gb 15.000rpm (een stripe / mirror van 6 disken en een mirror van 2 disken)

Maar ik wil bijvoorbeeld naar 8 x 146Gb 10.000rpm ( een stripe / mirror van 8 disken)
of naar 10 x 146Gb 10.000rpm (een stripe / mirror van 10 disken)

die keuze ligt dus aan de snelheid?

wat is sneller? Hoe bereken ik dat?
- een stripe van 3 x 73,4Gb 15.000rpm
- een stripe van 4 x 146Gb 10.000rpm

(het liefst zou ik een tooltje hebben die het berekend, want ik moet misschien nog meer combinaties berekenen...)

[ Voor 12% gewijzigd door Verwijderd op 14-02-2006 13:20 ]

[Boudewijn]

ligt er ook aan wat voor disks het zijn he

U320? U160? FC? SAS? ordinaire sata?

welk merk disks?
controller?

[Verwijderd]

Boudewijn schreef op dinsdag 14 februari 2006 @ 11:15:
ligt er ook aan wat voor disks het zijn he

U320? U160? FC? SAS? ordinaire sata?

welk merk disks?
controller?

Ze komen te zitten in een IBM TotalStorage DS300 en het zijn IBM U320 disken.

[Rolfie]

Het is inderdad nog wel wat gemakkelijker om te melden over werk merk het gaat. Software matige RAID of hardware matige RAID. Hier zit ook een wereld van verschil in.

[Bierkameel]

Verwijderd schreef op dinsdag 14 februari 2006 @ 11:13:
wat is sneller?
- een stripe van 3 x 73,4Gb 15.000rpm
- een stripe van 4 x 146Gb 10.000rpm

Define sneller?

Hogere doorvoersnelheid of lage accestime?

Ik weet zeker dat 4 x 146GB 10K sneller is qua doorvoorsnelheid want een even aantal schijven in een RAID0 is vreemd genoeg altijd sneller.
Voor een lage accestime moet je de 15K's nemen

[ Voor 8% gewijzigd door Bierkameel op 14-02-2006 11:42 ]

[Verwijderd]

Bierkameel schreef op dinsdag 14 februari 2006 @ 11:42:
[...]

Define sneller?

Hogere doorvoersnelheid of lage accestime?

Ik weet zeker dat 4 x 146GB 10K sneller is qua doorvoorsnelheid want een even aantal schijven in een RAID0 is vreemd genoeg altijd sneller.
Voor een lage accestime moet je de 15K's nemen

Hoezo dat dan? een even aantal schijven altijd sneller??

Als ik 3 snelle 15k schijven in een stripe zet zijn ze natuurlijk sneller dan 4 hele langzame....

Er draait voornamelijk SQL op, dus een lage accestime...

maar er is natuurlijk ergens overgang wanneer een stripe van 10K schijven sneller wordt dan een kleinere stripe van 15k schijven...

ik wil het kunnen berekenen.... niet gissen, van dat zal wel sneller zijn... Dus antwoorden van dit en dat is sneller heb ik eerlijk gezegd niks aan....

[ Voor 27% gewijzigd door Verwijderd op 14-02-2006 11:46 ]

[GH45T]

Verwijderd schreef op dinsdag 14 februari 2006 @ 11:44:
[...]


Hoezo dat dan? een even aantal schijven altijd sneller??

Als ik 3 snelle 15k schijven in een stripe zet zijn ze natuurlijk sneller dan 4 hele langzame....

dat moet je met een korreltje zout nemen, maar de performance winst van 4 tov 3 schijven is bijvoorbeeld groter dan 3 tov 2 schijven.

Ga je RAID 5 draaien dan wordt dit weer iets anders, veel fabrikanten adviseren dan juist 5 disks te gebruiken in plaats van 4 in verband met performancewinst.

Het ligt dus een beetje aan de situatie.

[BalusC]

dat moet je met een korreltje zout nemen, maar de performance winst van 4 tov 3 schijven is bijvoorbeeld groter dan 3 tov 2 schijven.

Heb je bronnen? De opschaling van de performance neemt in theorie af naarmate je meer schijven toevoegt Dit komt o.a. door de extra overhead, de wachttijden tijdens synchronisaties en een iets langere berekening van de RAID5 pariteit. Hoewel het laatste teniet kan worden gemaakt door een snelle I/O processor en veel cache. Neemt niet weg dat het per saldo sneller is overigens

En wat betreft 4x 10Krpm vs 3x 15Krpm: sja, dat hangt maar af van de merk/type schijf. Er zijn 10Krpm schijven die 'maar' 50MB/s halen en de andere halen 70MB/s. Zo ook voor 15Krpm schijven in de range van 70 à 100MB/s. Zo ook voor de I/O performance.

[GH45T]

BalusC schreef op dinsdag 14 februari 2006 @ 11:58:
Heb je bronnen? De opschaling van de performance neemt in theorie af naarmate je meer schijven toevoegt Dit komt o.a. door de extra overhead, de wachttijden tijdens synchronisaties en een iets langere berekening van de RAID5 pariteit. Hoewel het laatste teniet kan worden gemaakt door een snelle I/O processor en veel cache. Neemt niet weg dat het per saldo sneller is overigens

Ik had het ook niet over RAID5 maar over RAID0 RAID0 werkt gewoon over het algemeen gewoon sneller met een even aantal schijven

[Verwijderd]

Ok, even iets uitgebreider dan:

we hebben nu 1 vestiging waar gewoon een cluster draait met MSA500 Shared Storage. Hier zitten 8 x 73Gb 15k in.

de andere vestiging daar draaien op dit moment geen servers maar de PC's die hier staan maken rechtstreeks over 1Gbit glas.

De nieuwe situatie wordt als volgt:

op beide vestigingen komt IBM totalStorage te staan. De data die hier op staat wordt hoofdzakelijk gebruikt door een SQL server en een Exchange Server (HP Proliant DL380). De 2 vestigingen worden verbonden door 10Gbit glas. en de SQL-server op de ene vestiging schrijft zijn data weg op beide TotalStorage systemen (het zelfde geld voor de Exchange server op de andere vestiging). Dit gebeurt doormiddel van Veritas Storage Foundation software.

Nu we toch de disken moeten vervangen willen we dit dus gelijk sneller en groter hebben.

daarom wil ik dus weten of een stripe van 4x of 5x 146Gb 10K sneller is dan een stripe van 3x 73Gb 15K

hopelijk is het zo wat duidelijker....

[ Voor 3% gewijzigd door Verwijderd op 14-02-2006 13:02 ]

[BalusC]

RAID0 werkt gewoon over het algemeen gewoon sneller met een even aantal schijven

Ah, je hebt het over een even aantal schijven

daarom wil ik dus weten of een stripe van 4x of 5x 146Gb 10K sneller is dan een stripe van 3x 73Gb 15K

Nogmaals:

En wat betreft 4x 10Krpm vs 3x 15Krpm: sja, dat hangt maar af van de merk/type schijf. Er zijn 10Krpm schijven die 'maar' 50MB/s halen en de andere halen 70MB/s. Zo ook voor 15Krpm schijven in de range van 70 à 100MB/s. Zo ook voor de I/O performance.

[ Voor 103% gewijzigd door BalusC op 14-02-2006 12:12 ]

[Verwijderd]

BalusC schreef op dinsdag 14 februari 2006 @ 12:11:
[...]
Ah, je hebt het over een even aantal schijven


[...]
Nogmaals:
[...]

Nogmaals:

mijn vraag: Hoe bereken ik dit? Is hier een tooltje voor ofzo?

[BalusC]

Het lijkt me dus nogal wiedes als je even uitzoekt wat de snelheid van de schijven is. Dat was ook mijn inkopper

[Verwijderd]

BalusC schreef op dinsdag 14 februari 2006 @ 12:23:
Het lijkt me dus nogal wiedes als je even uitzoekt wat de snelheid van de schijven is. Dat was ook mijn inkopper

Doe je nou alsof, of snap jij mij echt niet?

Ik snap dat ik moet weten hoe snel de schijven per stuk zijn.... logisch, dat wist ik al voordat ik hier dit topic opende.

Maar ik kan me voorstellen dat er nog veel meer dingen belangrijk zijn:
- de capaciteit van de IBM totalStorage.
- het aantal schijven.
- heeft zoveel schijven wel zin? Misschien kom ik dan wel boven de snelheid wat het storage aan kan. etc. etc.


Hoe bereken ik het?

Ik neem de snelheid van een schijf, kan ik dat dan zomaar vermenigvuldigen met het aantal schijven in de stripe voor de totale snelheid?

etc. etc.

Nogmaals: hoe bereken ik het?

[John2B]

Doe je nou alsof, of snap jij mij echt niet?

BalusC is niet de enige die het niet snapt, ik namelijk ook niet.

Ik snap dat ik moet weten hoe snel de schijven per stuk zijn.... logisch, dat wist ik al voordat ik hier dit topic opende.

Als je dit snapt, waarom vraag je dat dan zo specifiek?

Maar ik kan me voorstellen dat er nog veel meer dingen belangrijk zijn:
- de capaciteit van de IBM totalStorage.
- het aantal schijven.
- heeft zoveel schijven wel zin? Misschien kom ik dan wel boven de snelheid wat het storage aan kan. etc. etc.

Kijk, als dat je vraagt is dan begrijp ik wat je bedoelt.

Toch blijft de vraag van BalusC staan aangezien die gegevens globaal bijdragen aan de totale berekening, of het wordt natte vinger werk en dat is niet wat je wilt.

[BalusC]

Hoe bereken ik het?

Ik neem de snelheid van een schijf, kan ik dat dan zomaar vermenigvuldigen met het aantal schijven in de stripe voor de totale snelheid?

Inderdaad zo ongeveer. Vandaar mijn opmerking dat je eerst de snelheid van de schijven moet weten. Lijkt me toch duidelijk? Geef hier gewoon de exacte merk/type schijven op, dan komen we er samen wel uit

[Verwijderd]

John2B schreef op dinsdag 14 februari 2006 @ 13:04:
[...]


BalusC is niet de enige die het niet snapt, ik namelijk ook niet.


[...]


Als je dit snapt, waarom vraag je dat dan zo specifiek?


[...]


Kijk, als dat je vraagt is dan begrijp ik wat je bedoelt.

Toch blijft de vraag van BalusC staan aangezien die gegevens globaal bijdragen aan de totale berekening, of het wordt natte vinger werk en dat is niet wat je wilt.

pfff... nee de vraag van hoe snel die schijven per stuk zijn is helemaal niet van belang!!!

De snelheid van de schijven in mijn vraag is gewoon "de snelheid van de schijven"

Daarom zei ik al duidelijk dat ik wil weten HOE ik het bereken. HOE HOE en nog eens HOE. Ik wil geen antwoord op de vraag zelf, maar hoe bereken ik het???

dus bijvoorbeeld: snelheid = "snelheid van de schijven" x "aantal schijven" x "aantal toeren" (mits de totale snelheid dan niet boven de throughput van het Storage uitkomt). etc. etc. etc.

de volgende twee vragen staan in mijn eerst post:
"weet iemand of er een tooltje beschikbaar is om te bereken hoe snel een stripeset gaat worden?"
"wat is sneller? Hoe bereken ik dat?"

sorry, maar lijkt me toch echt duidelijk...

[ Voor 13% gewijzigd door Verwijderd op 14-02-2006 13:22 ]

[BalusC]

Er is hier geen rekenmodule voor. Je moet gewoon de exacte specs van de controller en de schijven opgeven en ook de exacte configuratie (hoeveel kanalen? hoeveel schijven per kanaal?), dan kunnen we een schatting maken. That's it.

[ Voor 21% gewijzigd door BalusC op 14-02-2006 13:21 ]

[Femme]

Verwijderd schreef op dinsdag 14 februari 2006 @ 12:28:
[...]


Doe je nou alsof, of snap jij mij echt niet?

Ik snap dat ik moet weten hoe snel de schijven per stuk zijn.... logisch, dat wist ik al voordat ik hier dit topic opende.

Maar ik kan me voorstellen dat er nog veel meer dingen belangrijk zijn:
- de capaciteit van de IBM totalStorage.
- het aantal schijven.
- heeft zoveel schijven wel zin? Misschien kom ik dan wel boven de snelheid wat het storage aan de kan. etc. etc.


Hoe bereken ik het?

Ik neem de snelheid van een schijf, kan ik dat dan zomaar vermenigvuldigen met het aantal schijven in de stripe voor de totale snelheid?

etc. etc.

Nogmaals: hoe bereken ik het?

Hier is geen simpele berekening voor. Je kunt wel de sequentiële transfer rate en die vermenigvuldigen met het aantal stripes om een idee te krijgen van de STR in een perfect schalende RAID-configuratie, maar dat zegt weinig over de I/O performance van de configuratie in jouw database-applicatie. Er zijn veel factoren die invloed hebben op de prestaties, zoals de performance van de individuele schijven (het is mogelijk dat nieuwe generatie 10K-schijven bijna net zo snel zijn als oude generatie 15K-schijven) en het vermogen van de RAID-controller op de prestaties te laten schalen in jouw type toepassing. De prestaties schalen vrijwel nooit lineair met het aantal schijven. Dat lukt alleen als in academische omstandigheden als je bijvoorbeeld alleen sequentiële toegangspatronen hebt en de controller perfect schaalt met de toegenomen transfer rate, of wanneer je puur willekeurige I/O doet met zeer groot aantal gelijktijdig uit te voeren I/O's. In de praktijk pakt dan anders uit. Je hebt bijvoorbeeld de invloed van de cache, die ervoor kan zorgen dat een RAID-controller met één schijf bijvoorbeeld al 20 procent sneller is dan een domme controller zonder cache, maar als er dan meer schijven bijkomen schaalt de slimme RAID-controller ten opzichte van zijn reeds goede resultaat met één schijf relatief minder dan de domme controller schaalt ten opzichte van het slechte resultaat met één schijf. Allemaal factoren die je niet zomaar in een formule kunt vastleggen.

[BalusC]

Je kan het beter uitleggen, Femme

[Verwijderd]

Femme schreef op dinsdag 14 februari 2006 @ 13:29:
[...]


Hier is geen simpele berekening voor. Je kunt wel de sequentiële transfer rate en die vermenigvuldigen met het aantal stripes om een idee te krijgen van de STR in een perfect schalende RAID-configuratie, maar dat zegt weinig over de I/O performance van de configuratie in jouw database-applicatie. Er zijn veel factoren die invloed hebben op de prestaties, zoals de performance van de individuele schijven (het is mogelijk dat nieuwe generatie 10K-schijven bijna net zo snel zijn als oude generatie 15K-schijven) en het vermogen van de RAID-controller op de prestaties te laten schalen in jouw type toepassing. De prestaties schalen vrijwel nooit lineair met het aantal schijven. Dat lukt alleen als in academische omstandigheden als je bijvoorbeeld alleen sequentiële toegangspatronen hebt en de controller perfect schaalt met de toegenomen transfer rate, of wanneer je puur willekeurige I/O doet met zeer groot aantal gelijktijdig uit te voeren I/O's. In de praktijk pakt dan anders uit. Je hebt bijvoorbeeld de invloed van de cache, die ervoor kan zorgen dat een RAID-controller met één schijf bijvoorbeeld al 20 procent sneller is dan een domme controller zonder cache, maar als er dan meer schijven bijkomen schaalt de slimme RAID-controller ten opzichte van zijn reeds goede resultaat met één schijf relatief minder dan de domme controller schaalt ten opzichte van het slechte resultaat met één schijf. Allemaal factoren die je niet zomaar in een formule kunt vastleggen.

Kijk, dat is duidelijke taal... nou snap ik tenminste waarom jullie de specs van de apparatuur willen hebben.

Het kan aan mij liggen, maar ik had het idee dat iedereen alleen maar voor mij wilde rekenen. Ik wil zelf rekenen, maar ik wist niet precies hoe...

Maar aangezien er zoveel factoren van afhankelijk zijn wordt het inderdaad vrij lastig!

[wezep]

Verwijderd schreef op dinsdag 14 februari 2006 @ 12:11:
Ok, even iets uitgebreider dan:

we hebben nu 1 vestiging waar gewoon een cluster draait met MSA500 Shared Storage. Hier zitten 8 x 73Gb 15k in.

de andere vestiging daar draaien op dit moment geen servers maar de PC's die hier staan maken rechtstreeks over 1Gbit glas.

De nieuwe situatie wordt als volgt:

op beide vestigingen komt IBM totalStorage te staan. De data die hier op staat wordt hoofdzakelijk gebruikt door een SQL server en een Exchange Server (HP Proliant DL380). De 2 vestigingen worden verbonden door 10Gbit glas. en de SQL-server op de ene vestiging schrijft zijn data weg op beide TotalStorage systemen (het zelfde geld voor de Exchange server op de andere vestiging). Dit gebeurt doormiddel van Veritas Storage Foundation software.

Nu we toch de disken moeten vervangen willen we dit dus gelijk sneller en groter hebben.

daarom wil ik dus weten of een stripe van 4x of 5x 146Gb 10K sneller is dan een stripe van 3x 73Gb 15K

hopelijk is het zo wat duidelijker....

Maar draaien jullie een (belangrijke?) applicatie die gebruikt maakt van MS SQL Server op een stripe set? Dus 1 schijf kapot en gelijk kan een hele vestiging niet meer draaien?
Ik zou op z'n minst met een raid5 set gaan draaien. En dan nog het liefst een spare erbij.
Vertel eens hoeveel mensen zijn er afhankelijk van deze applicatie/database?

[Verwijderd]

wezep schreef op dinsdag 14 februari 2006 @ 13:53:
[...]

Maar draaien jullie een (belangrijke?) applicatie die gebruikt maakt van MS SQL Server op een stripe set? Dus 1 schijf kapot en gelijk kan een hele vestiging niet meer draaien?
Ik zou op z'n minst met een raid5 set gaan draaien. En dan nog het liefst een spare erbij.
Vertel eens hoeveel mensen zijn er afhankelijk van deze applicatie/database?

Het zijn stripe-mirrors, dus volledig gemirrorde stripes.

Dus 4 disken stripe is 8 disken stripe-mirror. Elke disk mag dus uitvallen en er kunnen er zelfs 4 tegelijk defect gaan. (mits het de goede zijn....)

[BalusC]

RAID01 dus.

En heb je de exacte specs/configuratie nog niet bij de hand? Aangezien je daar nog niet over hebt gerept

[John2B]

BalusC schreef op dinsdag 14 februari 2006 @ 14:03:
RAID01 dus.

En heb je de exacte specs/configuratie nog niet bij de hand? Aangezien je daar nog niet over hebt gerept

daar gaat hij ook niet over reppen, want de vraag is HOE hij die berekening moet gaan maken en is niet de bedoeling dat wij dat voor hem gaan uitrekenen.

Op zich zou dat best leuk zijn, dan hebben we er allemaal wat aan om te zien hoe deze case GLOBAAL uitpakt, maar zoals zoals Femme al opmerkt niet echt eenvoudig om dit in een eenvoudige berekening/formule uit te drukken.

[Verwijderd]

John2B schreef op dinsdag 14 februari 2006 @ 15:00:
[...]


daar gaat hij ook niet over reppen, want de vraag is HOE hij die berekening moet gaan maken en is niet de bedoeling dat wij dat voor hem gaan uitrekenen.

Op zich zou dat best leuk zijn, dan hebben we er allemaal wat aan om te zien hoe deze case GLOBAAL uitpakt, maar zoals zoals Femme al opmerkt niet echt eenvoudig om dit in een eenvoudige berekening/formule uit te drukken.

De specs zal ik even bij elkaar zoeken. Kijk later hier nog even... dan zullen ze er staan. (Het kan zijn dat het morgen pas wordt.)

[BalusC]

Als hij daar geen informatie over prijsgeeft, dan kunnen we helaas geen schatting maken en dan heeft hij nog steeds geen antwoord op zijn initiële vraag: welke is beter, 4x 10Krpm of 3x 15Krpm

edit:

OK, morgen dus

[ Voor 8% gewijzigd door BalusC op 14-02-2006 15:06 ]

[Bierkameel]

Een beetje SQL server doet sowieso niet zoveel op de schijven.
We hebben hier een ERP pakket met een SQL DB van 206GB maar die heeft bijna geen I/O op de schijven (MSA1000 SAN) dankzij het 8GB geheugen in de server.

Hoeveel geheugen heb je eigenlijk in die server?

[Femme]

Dat hangt natuurlijk sterk af van de specifieke toepassing. Als er veel in de database wordt geschreven is disk I/O onvermijdelijk. Extra geheugen zal altijd wel helpen bij een grote database, maar als de dataset erg groot is er weinig repetitie is in de gegevens die worden aangesproken zal er alsnog veel read I/O plaatsvinden.