SAN Raid level (Raid5 of Raid10)

[Verwijderd]

Beste Tweakers,

Een vraagje waar ik zo snel geen antwword op gevonden kreeg.

Als je een SAN hebt met 16 disken (Equallogic unit met 16x450GB SAS 15K) er in op Raid50 en deze spiegelt tegen een HP DL380G5 server met 4 schijven van 72GB SCSI in Raid10 is het dan zo dat de Raid10 alsnog sneller is als de Raid50 in een SAN ?

Dus hoe word een en ander gemeten ?
Ik begreep dat een Equallogic PS6000XV SAN met 16 schijven alle schijven volledig benut voor performance.

Waarom de vraag ?
Ik zit te dubben of ik een Equallogic PS6000XV SAN volledig op Raid10 of op Raid50 moet zetten. Want netto scheelt het natuurlijk nog al wat aan capaciteit.
Een van de servers is een SQL server welke er op komt te staan met zijn schijven. Daar zit een database van ong 60 GB op (o.a Sharepoint en Navision).
In de meeste gevallen zet je SQL op Raid10 maar omdat je nu de snelheid van alle hardisken pakt vraag ik me dus af of Raid10 noodzakelijk is.
Er komen ook 2 Fileservers (600GB) op en de Exchangestore (100GB) met 120 domainusers.

Hardware SAN:Equallogic PS6000XV (3400 iops)
16x450GB 15K

[ThomVis]

Hangt ook een beetje van de lees/schrijf verhouding af. Als je voornamelijk leesacties heb wil je zoveel mogelijk spindels aanspreken, wat met RAID5 beter lukt als met RAID10 (met dezelfde hoeveelheid schijven). Heb je meer schrijfacties kan misschien het beter zijn RAID10 te pakken.
Ik ben bang dat je beide situaties zelf moet testen met bijvoorbeeld iometer.
Bij ons draaide alle virtuele disken van de servers (120 stuks) op het SAN op RAID5, en hebben nooit de noodzaak gehad dat op RAID1 te zetten.

[ Voor 16% gewijzigd door ThomVis op 01-06-2010 19:02 ]

[Verwijderd]

Een antwoord geven op basis van deze input is lastig. Wat oa invloed heeft:

SAN:

Type switch voor het SAN network? Jumbo en flow aan op alle apparatuur? Welke NIC(s) in de server? 1 NIC geeft je maar 1Gbit/s naar het SAN.

Server:

4x 72GB 15k SAS disks? Welke RAID controller?

Een beetje RAID controller komt richt 3Gbit/s en als er nog meer servers op je SAN gaan toegrijpen dan zal de lokale RAID set altijd wel sneller blijven als je daar bv alleen je navision DB op zet.

De vraag is ook welke performance je nodig hebt, en welke features je wilt gebruiken. Als je bv snaps wilt maken, of data repliceren dan zit je toch snel aan een SAN vast.

Oh, meten is inderdaad de beste optie. Er zijn voldoende gratis tools om een goede indicatie te krijgen. Het SAN zou ik in ieder geval op RAID 50 configureren denk ik.

[ Voor 11% gewijzigd door Verwijderd op 01-06-2010 20:51 ]

[Midas.e]

Laat eerst een een IO meting doen, zonder meting kan je niet vooruit komen.

[Verwijderd]

We hebben een io meting gehad en die gaf aan dat we 2300 iops nodig hebben in een 70/30 read/write verhouding.
Wat er verder uitkwam is dat de meeste io's door de backup gepakt werden welke vanaf 17.00 uur begint te lopen. We zijn een traditioneel bedrijf met werktijden van ong 7.00 - 18.00 uur
Door de backup wat slimmer in te gaan delen moeten de iops verder naar beneden gaan, we doen nu nml niets speciaals met de backup (alles dageljks full) en daar kunnen we ook nog wat slagen slaan door bv de-duplicatie enz.
We willen een snelle unit (3500iops) aanschaffen voor de actieve data (FP/SQL/EX) en een "trage" unit (900iops) voor backup en archief.
Met die unit van 3500 iops zijn we ook voorzien op groei qua snelheidbehoefte van disken.

De meting is gedaan op basis van dat alles op 1 bak komt en we gaan het dus waarschijnlijk splitsen door de backup en archief er uit te trekken en dit op een SATA San te zetten (Equallogic PS4000E 16x1TB)

[ThomVis]

Uit nieuwsgierigheid: Waarmee/hoe is die meting uitgevoerd?

[SpamLame]

Ook hier alleen VRAID5 LUN's op onze diskarray's.
Of RAID10/50 whatever voor jou nodig is is deels afhankelijk van hoe groot de (Write) Cache van de Equallogic's zijn.

[Verwijderd]

De meting is gedaan middels het uitlezen van de performancecounters van de servers welke aan het San komen.

Hoe zie ik wat de writecache is van de units ?

[SpamLame]

Verwijderd schreef op woensdag 02 juni 2010 @ 13:28:
De meting is gedaan middels het uitlezen van de performancecounters van de servers welke aan het San komen.

Hoe zie ik wat de writecache is van de units ?

datasheets/ specs/ adminguides indien instelbaar?

Gevonden
http://www.dell.com/downl...ps6000xv_specsheet_nl.pdf
4Gig indien dual controllers, maar de write cache zal wel gemirrored zijn dus effectief wordt het minder.
Hoeveel minder is niet uit de specsheet te halen.

[ Voor 29% gewijzigd door SpamLame op 02-06-2010 15:00 . Reden: specsheet gevonden ]

[Question Mark]

Verwijderd schreef op woensdag 02 juni 2010 @ 09:42:
We hebben een io meting gehad en die gaf aan dat we 2300 iops nodig hebben in een 70/30 read/write verhouding.

zoek dan gewoon de specs van je disks op en reken uit hoeveel IOPS je haalt in een bepaalde config. Hier staat bijvoorbeeld een aardige IO calculator.

Dat geeft je een aardige indicatie.

[Verwijderd]

Question Mark schreef op woensdag 02 juni 2010 @ 15:01:
[...]

zoek dan gewoon de specs van je disks op en reken uit hoeveel IOPS je haalt in een bepaalde config. Hier staat bijvoorbeeld een aardige IO calculator.

Dat geeft je een aardige indicatie.

Maar hoe bereken ik dan wat een bepaalde applicatie vraagt aan IO ?

[Question Mark]

Dat hoef je niet te bereken, je had immers al je IO-requirements gemeten en bepaald.

Er zijn een hoop IO-calculators te vinden op het internet waar je enkel de IOPS van een enkele disk in hoeft te voeren en hoeveel IO je wilt halen aan client-side (in jullie geval 2300 IOPS in een 70/30 verhouding). De calculators geven dan wel aan hoeveel disken in een bepaald RAID-level moeten staan om de IO's te halen.

De calculator die ik hierboven aanhaal geeft aan dat om 2300 IOPS te halen in een 70/30 verhouding) en uitgaande dat een enkele SAS-disk 200 IOPS kan leveren, er 16 SAS disken in een RAID 10 gezet moeten worden om dit te halen.

Uiteraard zijn dit uitgangspunten en is eea nog afhankelijk van type controller, en de hoeveelheid cache en dergelijke.

[Verwijderd]

Question Mark schreef op woensdag 02 juni 2010 @ 15:31:
Dat hoef je niet te bereken, je had immers al je IO-requirements gemeten en bepaald.

Er zijn een hoop IO-calculators te vinden op het internet waar je enkel de IOPS van een enkele disk in hoeft te voeren en hoeveel IO je wilt halen aan client-side (in jullie geval 2300 IOPS in een 70/30 verhouding). De calculators geven dan wel aan hoeveel disken in een bepaald RAID-level moeten staan om de IO's te halen.

De calculator die ik hierboven aanhaal geeft aan dat om 2300 IOPS te halen in een 70/30 verhouding) en uitgaande dat een enkele SAS-disk 200 IOPS kan leveren, er 16 SAS disken in een RAID 10 gezet moeten worden om dit te halen.

Uiteraard zijn dit uitgangspunten en is eea nog afhankelijk van type controller, en de hoeveelheid cache en dergelijke.

Als een enkele disk (SAS 15K) 200iops kan leveren dan zeg je eigenlijk ook dat als we RAID5(0) inzetten dat we met 16 disken niet weg komen. Dan klpt de opgave van mijn leverancier in de verste verte niet. Die geeft aan dat de unit 3400 iops kan verwerken.

[SpamLame]

Verwijderd schreef op woensdag 02 juni 2010 @ 16:12:
[...]


Als een enkele disk (SAS 15K) 200iops kan leveren dan zeg je eigenlijk ook dat als we RAID5(0) inzetten dat we met 16 disken niet weg komen. Dan klpt de opgave van mijn leverancier in de verste verte niet. Die geeft aan dat de unit 3400 iops kan verwerken.

Wellicht is dat de waarde (burst) die bereikt wordt gedurende een korte tijd (lees dat dan de cache vol is).

[Verwijderd]

Je leverancier geeft je deze waarden waarschijnlijk door zo'n partner calculator van equallogic zelf. Ik heb zelf erg vaak met deze SANs gewerkt en deze configureren we bijna altijd in raid 50. Dit raid niveau icm met MPIO verbindingen zetten we ze achter ESX waarna we ongeveer 3000 IOPS per SAN halen. Bij uitbreiding zal het volume zich spreiden over meerdere SANs waarbij ook de aantal IOPS vergroot wordt.

In de grotere omgevingen worden er vaak een grote hoeveelheid spindels tegenaan gegooid.

[Question Mark]

Verwijderd schreef op woensdag 02 juni 2010 @ 16:12:
[...]
Als een enkele disk (SAS 15K) 200iops kan leveren dan zeg je eigenlijk ook dat als we RAID5(0) inzetten dat we met 16 disken niet weg komen.

Niet helemaal, ik zeg er nl. bij dat het een uitgangspunt is dat eea afhankelijk is van oa. de hoeveelheid cache op de controllers.

[Verwijderd]

Ik hoorde vandaag een collega van een ander bedrijf opperen dat de nieuwe Exchange server 2010 beter performed dan 2003 en zelfs op SATA disken goed draait.
We zitten er aan te denken om 2010 in te gaan zetten, en dit heeft natuurlijk ook met een implementatie van een SAN te maken.
Dit even tussen door

[Yalopa]

Staar je niet blind op de IOPs waarden die fabrikanten geven. Deze testen alijd in de meest optimale omstandigheden. Toevallig werk ik ook met equallogic, en toevallig is mijn collega een zeer gedreven SQL DBA. We hebben al enkele malen het beestje gestrest met SQLIO en de resultaten van deze tests lopen erg uiteen afhankelijk van het patroon vande IO, wij haalden tot 5000 iops uit 2 PS5000 met 10K disken op raid 10 (2 NICs op de servers, die zaten vol) maar dat was dus enkel met bepaalde patronen.

De performantie winsten die in de SQL omgeving waar ik werk gehaald worden zijn hoofdzakelijk gerealiseerd door optimalisatie van de queries en de code. Nu overwegen we zelf om de databases op RAID 50 (sata) te gooien, de logfiles blijven wel op de raid 10. Als we dat testen.

Equallogic is leuk en eenvoudig spul, maar echt leuk (performant) wordt het pas als je enkele dozen hebt, vanaf dan is het ook duur. Mischien kan je dan eens gaan kijken wat andere vendors met jou budget aankunnen, ga je voor gemak of voor brute performantie...

[Bierkameel]

De eerste fout die je maakt is dat je alles van SQL op 1 RAIDgroup wil plaatsen.
Ideaal is de DB in RAID 1 of RAID10 want RAID5 is niet snel genoeg qua schrijven.

Ook de logfiles wil je niet in dezelfde RAIDgroup als je database, het liefst zelfs 2 schijven in RAID0 of ook RAID10 als je de snelheid echt nodig hebt.

[Yalopa]

@Bierkameel

Zo werkt equallogic niet, op equallogic kies je je raidvollume per box, je hoeft geen disk groepen aan te maken, wel maak je pools aan van boxen (raid mixen mag), waarover een volume kan uitgesmeerd worden, een volume wordt automatisch over maximaal 3 boxen uitgesmeerd, als je wil kan je wel het RAID level bepalen. Hoe meer boxen in de pool hoe meer performantie.

Vergelijkbaar met lefthand dus

Als RAID 50 de IOPS levert die je wenst volgens jou patroon, waarom zou je dan naar een RAID 10 gaan om dan vast te stellen dat je DB die IOPS nooit vraagt?

[Question Mark]

Bierkameel schreef op maandag 07 juni 2010 @ 16:12:
Ook de logfiles wil je niet in dezelfde RAIDgroup als je database, het liefst zelfs 2 schijven in RAID0 of ook RAID10 als je de snelheid echt nodig hebt.

Dit heeft niet zo veel met performance te maken. Het read/write patroon van logfiles is voornamelijk sequentieel en is niet zo spannend.

Het scheiden van database en logfiles heeft meer met recoverabilty van je DB's te maken. Zou je deze op dezelfde raidgroup plaatsen en deze failed dan kun je niet meer naar elk point in time restoren (enkel een backup terugplaatsen).

Zou je db en logfiles scheiden dan kan het volgende gebeuren:

• Raidgroup van de DB failed -> DB restoren van backup en een replay van je logfiles brengt je db's weer up-to-date. Geen data kwijt.
• Raidgroup van de logfiles failed -> DB is nog compleet intact, geen data kwijt.

[Verwijderd]

Yalopa schreef op maandag 07 juni 2010 @ 19:34:
@Bierkameel

Als RAID 50 de IOPS levert die je wenst volgens jou patroon, waarom zou je dan naar een RAID 10 gaan om dan vast te stellen dat je DB die IOPS nooit vraagt?

Bovenstaand is dus ook altijd mijn insteek.....waarom iets instellen of aankopen als je het toch niet nodig hebt ? Ik zie meer in zaken aftikken op basis van onderzoek.....meten is weten.
Het scheiden van de database en logs kan ik wel volgen. Hoe dit dan weer in te stellen op de Equallogic is me niet geheel duidelijk omdat het eigenlijk 1 grote Raid bak is. Wat nog zou kunnen is bv de Logs op de 2e unit met de Sata schijven zetten (PS4000E).