optimale IOPS config voor Oracle op 12 TB EMC SAN

[Verwijderd]

Hallo,

De situatie:
EMC SAN 37 SAS 15K schijven in RAID 5 (4+1), paar TB data
Oracle database met continue writes en random reads.
RAID5 om kosten te drukken, dus geen RAID1+0 mogelijk

Elke RAID5 is 1 LUN (7 in totaal)
Elke LUN is mounted op een andere directory, ext3.
Oracle database files zijn 1 voor 1 op een andere LUN (directory) geplaatst.
Datafile 1 & 8 staan op LUN1, datafile 2 & 9 staan op LUN2.

En volgens mij ben ik nu mijn snelle IOPS kwijt doordat ik aparte LUNs heb met aparte datafiles. Dit zorgt er, volgens mij, voor dat er eerst heftig op LUN1 wordt geschreven en daarna op LUN2, enz. I.p.v. tegelijkertijd gebruikmakend van alle disk controllers. Kan iemand dat bevestigen?

Ik heb er wakker van gelegen en ben bang dat ik de config moet omgooien.

Kan iemand mij de beste, met de huidige middelen (& eis RAID5), uitleggen?

Wat ik heb bedacht:
Alle RAID5 groepen in 1 LUN. XFS als filesystem (ext3 had 2TB limit). & rockin'

Zijn er SAN/Oracle specialisten die mij advies kunnen geven?

Alvast bedankt,

IR1eBcA1g2nm22W

[ZeRoC00L]

Wat zei je SAN leverancier toen je deze vraag bij hun stelde?

[Rolfie]

ZeRoC00L schreef op dinsdag 18 januari 2011 @ 09:11:
Wat zei je SAN leverancier toen je deze vraag bij hun stelde?

Of heb je gewoon maar wat besteld?
Wat voor een SAN heb je precies? en hoe is die opgebouwd?
FC of ISCSI?
Wat wil je bereiken?
Waarom heb je deze opzet gekozen?

Dit zijn nog al belangrijke vragen om ook maar iets te roepen.

RAID5 om kosten te drukken, dus geen RAID1+0 mogelijk

[SpamLame]

Welk storage array heb je van EMC? Ik vermoed een Clariion, klopt dat.

Ik geloof zelfs dat Oracle het SAME principe als best practise hanteerd.
SAME staat voor Stripe And Mirror Everywhere.

Wat je zou kunnen doen is naar je database kijken en de meeste IO genererende tables/logs op R1 (toch) zetten, R5 dan gebruiken voor de overige delen.
Evenwel zou je kunnen denken aan stripe Meta's om te zorgen dat er meer drives meedoen in een IO.
Als ik je goed begrepen heb, ligt elk LUN op 5 disken. Afhankelijk van wat je aan de op de frontend aanlevert is het mogelijk dat de backend dat niet verwerken kan vanweg IO starvation

Is er bij de samenstelling ook een oracle meneer aanwezig geweest en is het database design aangepast op de storage array??

Is er ook een OS beheerder bij geweest en is wellicht het OS aangepast op de storage array?

[ Voor 110% gewijzigd door SpamLame op 18-01-2011 10:54 ]

[ThomVis]

Verwijderd schreef op dinsdag 18 januari 2011 @ 08:26:
Hallo,

De situatie:
EMC SAN 37 SAS 15K schijven in RAID 5 (4+1), paar TB data
Oracle database met continue writes en random reads.
RAID5 om kosten te drukken, dus geen RAID1+0 mogelijk

Met RAID5 heb je met writes altijd een performance-penalty door de parity. Door daar RAID1 van te maken win je al veel. En wat SpamLame al aangeeft, is het niet mogelijk de database files op RAID5 en de transaction logs op RAID1 te zetten?

En vertel je hier dat elke RAID5 set uit 5 schijven bestaat?
Elke SAS 15K schijf heeft ongeveer 150-160 IOPS, dus elke LUN zou op 150*5=750 IOPS uitkomen. Als grotere LUNS kan maken met meer schijven gaat je performance per LUN omhoog.
Zal je wel moeten controleren of de controllers van die EMC het aankunnen, anders is het een academische discussie, maar dat zal wel los lopen.

[Question Mark]

ThomVis schreef op dinsdag 18 januari 2011 @ 19:29:
[...]
Elke SAS 15K schijf heeft ongeveer 150-160 IOPS, dus elke LUN zou op 150*5=750 IOPS uitkomen.

Zo kort door de bocht kun je dat niet stellen. Dit is (zeker bij Raid5) sterk afhankelijk van de verhouding tussen read en write acties.

[Verwijderd]

Nou inderdaad.
Ik heb bij de SAN leverancier aangegeven wat het moest kunnen en dit is er uit gekomen...
Nee RAID1+0 is geen optie.
RAID5 = 4+1 dus IOPS is 4/5 van 750...
meer schijven in de RAID5 zorgt ervoor dat je voor bijv. 20 schijven maar 1 schijf stuk mag gaan. Nu zijn dat er 4.
Dus, een striped metalun creeeren van de aparte LUNs, hierdoor wordt de SAN ruimte als 1 disk gezien. Klopt dat?
Als ik vervolgens de datafiles van 4 GB plaats worden deze in data chunks van xKB / MB over de metalun en dus de verschillende LUNs geschreven en gelezen?

ALs ik dan XFS gebruik kan ik die paar TB hierop zetten. En worden, als ik dan een query doe, de btijes uit al de verschillende LUNs gevist?

[Question Mark]

Verwijderd schreef op woensdag 19 januari 2011 @ 12:46:
meer schijven in de RAID5 zorgt ervoor dat je voor bijv. 20 schijven maar 1 schijf stuk mag gaan. Nu zijn dat er 4.

Kun je niet voor één grote Raid6 kiezen? Je hebt dan twee disken waar parity op opgeslagen wordt, er mogen dan twee disken defect raken. In combinatie met online spare disk(s), zit je redelijk safe en heb je het voordeel van veel spindels in een grote diskgroup.

[mieJas]

Verwijderd schreef op dinsdag 18 januari 2011 @ 08:26:
XFS als filesystem (ext3 had 2TB limit)

Niet alleen dat. XFS presteert gewoon beter dan ext3 en blijft die prestaties ook aanhouden wanneer het volume voller loopt.

Het voorstel van Mark lijkt me wel wat. Eén grote groep, zodat je de spindels maximaal kan gebruiken. Als je genoeg cache in die EMC hebt zitten, moet je je niet zoveel zorgen maken over die write penalty van een RAID5 of 6.

[Remco]

Het is ook wel belangrijk om te weten hoeveel er nu precies gelezen en geschreven word.
Zoals eerder vermeld is Raid 5 goed om te lezen, maar niet zo snel om naar toe schrijven.
Aangezien een user niet direct naar de db schrijft zou het op zich geen probleem moeten zijn met Raid 5, maar ja; meten is weten.

[SpamLame]

Verwijderd schreef op woensdag 19 januari 2011 @ 12:46:
Nou inderdaad.
Ik heb bij de SAN leverancier aangegeven wat het moest kunnen en dit is er uit gekomen...

Wat heb je aangegeven dan globaal een idee of een IO profiel van wat het nu doet met groei prognoses?

Nee RAID1+0 is geen optie.

Wat niet volledig R10 of deels?
En waarom niet, red je het dan capaciteit technisch niet?
Is het geen dedicated oplossing?
Aangeschaft is het al dus duurder zal het niet worden indien de capaciteit toereikend is.

RAID5 = 4+1 dus IOPS is 4/5 van 750...
meer schijven in de RAID5 zorgt ervoor dat je voor bijv. 20 schijven maar 1 schijf stuk mag gaan. Nu zijn dat er 4.
Dus, een striped metalun creeeren van de aparte LUNs, hierdoor wordt de SAN ruimte als 1 disk gezien. Klopt dat?

Ja je geeft de MetaHead aan de host die het totaal ziet van alle members.

Als ik vervolgens de datafiles van 4 GB plaats worden deze in data chunks van xKB / MB over de metalun en dus de verschillende LUNs geschreven en gelezen?

Dat is afhankelijk van de configuratie striped dan ja, concatenated dan nee.

ALs ik dan XFS gebruik kan ik die paar TB hierop zetten. En worden, als ik dan een query doe, de btijes uit al de verschillende LUNs gevist?

Ja simpel gezegd "doet een Meta die uit 4 r5 (4+1) devices bestaat evenveel als een r5 device van 16+1."
Simpel want je krijgt overhead doordat je gaat stripen en daardoor moet je 4 keer parity gaat uitrekenen omdat je 4 R5's hebt.
En dan is er nog de afhankelijkheid van je controllers (lun ownership active passive blablaetc) of je hier winst uit haalt.

[ThomVis]

Verwijderd schreef op woensdag 19 januari 2011 @ 12:46:
RAID5 = 4+1 dus IOPS is 4/5 van 750...

My bad, maar dan heb je veel hotspares in je systeem. Kan je geen "global" hotspares instellen, en daar dan 2 iod voor pakken. Win je al 5 schijven voor data en IOPS.

Question Mark schreef op dinsdag 18 januari 2011 @ 19:34:
[...]
Zo kort door de bocht kun je dat niet stellen. Dit is (zeker bij Raid5) sterk afhankelijk van de verhouding tussen read en write acties.

Klopt, is ook een theoretisch maximum.

[erwinb]

4 * Raid 4+1 zorgt er voor dat er inderdaad 4 disken defect kunnen raken, echter zullen dat dan wel disken uit verschillende raid sets moeten zijn. Zelf zou ik ook kiezen voor een RAID6 config, dan kunnen er 2 willekeurige disken decect raken zonder dat er corruptie kan optreden.
google ook eens op "write penalty" om iets te lezen over IO's op een raid systeem.
Over een optimale performance, ik zou kiezen om dit EMC systeem met een XBlade uit te rusten, of als het een VNX is een licentie hiervoor (Maar bij de aanschaf van een nieuw systeem is die bijna gratis). en dan Oracle direct NFS te laten praten. Dat is een heel stuk sneller als een ander filesystem gebruiken, en je bebruikt de dure oracle cores waarvoor ze zijn bedoeld, het draaien van een database en niet het afhandelen van een filesysteem.

[Clueless]

EMC heeft ook prima best practices voor het draaien van Oracle DBMS op EMC Clariion.

Implementing Oracle on EMC CLARiiON Storage Systems - Best Practices Planning

EMC CLARiiON Storage Solutions: Oracle Database 10g/11g/11g R2 with CLARiiON Storage Replication Consistency - Applied Technology

Wellicht dat dit je kan helpen bij beter inzicht krijgen hoe Oracle op EMC Clariion te draaien.