RAID voor een database-server, hoe inrichten?

[Verwijderd]

Ik heb over het volgende onderwerp al een aantal verschillende meningen gehoord. Ik ben dus eigenlijk wel benieuwd hoe er hier over gedacht wordt.

Ik moet hier binnenkort een nieuwe database-server gaan installeren. We gaan gebruik maken van 4 identieke SCSI-HD's, het geheel moet fouttolerant zijn dus we kunnen gaan voor RAID1 of RAID5. We willen het besturingssysteem en het server-programma op 1 volume hebben en de databases op een tweede volume. We kunnen dus een RAID5 aanmaken van 4 schijven en op deze RAID5 de twee volumes aanmaken. Maar wat we ook kunnen doen, is 2 keer een RAID1 aanmaken en op elke RAID1 een volume aanmaken.

Met de opslagcapaciteit hoeven we niet echt rekening te houden, in beide gevallen zou dat nog meer dan genoeg zijn. Wat wel belangrijk is: 1. fouttolerantie, 2. performance onder normale omstandigheden en 3. performance als er een schijf uitvalt.

Het verschil onder punt 1 is volgens mij niet zo heel groot. In beide situaties kan er een schijf uitvallen zonder dat er gegevens verloren gaan. Ik zie een klein voordeeltje voor de situatie van 2x RAID1, maar dat is eigenlijk niet echt de moeite.

Over punt 2 twijfel ik dus. Welke van de twee situaties zou de beste performance leveren onder normale omstandigheden? De twee volumes samen op 1 RAID5 van 4 schijven of elk volume op zijn eigen RAID1?

Bij punt 3 heeft 2x RAID1 een voordeel. Maar dit punt is duidelijk ondergeschikt aan punt 2.


Corrigeer me maar, waar nodig.

[FastBunny]

2 volumes op je RAID5, snelste oplossing en redundant

RAID10 is ook een oplossing. Je hebt dan een stripe van 2 x een mirrored schijf. Erg snel

[deDorus]

Voor de performance is het beter je OS/App en data volumes fysiek te scheiden. Dus twee maal RAID 1 in dit geval.

[Verwijderd]

Persoonlijk ging mijn voorkeur ook naar 2x RAID1 i.v.m. het fysiek scheiden van OS/App en data. Een collega was dus van mening dat 2 volumes op een RAID5 sneller zou zijn.

[Verwijderd]

deDorus schreef op 20 februari 2004 @ 11:28:
Voor de performance is het beter je OS/App en data volumes fysiek te scheiden. Dus twee maal RAID 1 in dit geval.

Dat ben ik niet helemaal met je eens. Ik zou wel de swapfile apart plaatsen van het OS en de database. Ik zou het OS mirroren en de database raid 5

raid 1 voor performance (50% parity)
raid 5 voor redundancy (33% parity of minder, afhankelijk van config)

Zoiets als volgende :

raid 1 - partitie 0 - OS
raid 1 - partitie 1 - swapfile
raid 5 - partitie 0 - database

[ Voor 1% gewijzigd door Verwijderd op 20-02-2004 11:54 . Reden: me stupid fuck ;) ]

[FastBunny]

Verwijderd schreef op 20 februari 2004 @ 11:50:
[...]


Dat ben ik niet helemaal met je eens. Ik zou wel de swapfile apart plaatsen van het OS en de database. Ik zou het OS mirroren en de database raid 5

raid 0 voor performance (50% parity)
raid 5 voor redundancy (33% parity of minder, afhankelijk van config)

Zoiets als volgende :

raid 0 - partitie 0 - OS
raid 0 - partitie 1 - swapfile
raid 5 - partitie 0 - database

Raid 0 is striping, raid 1 is mirroring

[Verwijderd]

FastBunny schreef op 20 februari 2004 @ 11:52:
[...]

Raid 0 is striping, raid 1 is mirroring

ik zat het zelf net ook te lezen.. oopsie

[Verwijderd]

Verwijderd schreef op 20 februari 2004 @ 11:50:
[...]


Dat ben ik niet helemaal met je eens. Ik zou wel de swapfile apart plaatsen van het OS en de database. Ik zou het OS mirroren en de database raid 5

raid 1 voor performance (50% parity)
raid 5 voor redundancy (33% parity of minder, afhankelijk van config)

Zoiets als volgende :

raid 1 - partitie 0 - OS
raid 1 - partitie 1 - swapfile
raid 5 - partitie 0 - database

Ja, dat zou inderdaad ideaal zijn. Maar die optie heb ik zo niet met 4 schijven. Een extra schijf kost je welliswaar "slechts" een paar honderd euro, maar we moeten wel een beetje op de centen letten hier. (Zorg: toiletpapier is voor sommige instellingen tegenwoordig al een struikelblok, laat staan harde schijven.)

[Verwijderd]

Verwijderd schreef op 20 februari 2004 @ 12:00:
[...]

Ja, dat zou inderdaad ideaal zijn. Maar die optie heb ik zo niet met 4 schijven. Een extra schijf kost je welliswaar "slechts" een paar honderd euro, maar we moeten wel een beetje op de centen letten hier. (Zorg: toiletpapier is voor sommige instellingen tegenwoordig al een struikelblok, laat staan harde schijven.)

Tsja, dat zal je dus moeten motiveren :

Wat wel belangrijk is: 1. fouttolerantie, 2. performance onder normale omstandigheden en 3. performance als er een schijf uitvalt.

Maak een voorstel voor de organisatie en laat hun beslissen wat echt belangerijk is... en op basis daarvan je keuze maken... misschien roepen ze meteen (als jij een motivatie hebt gemaakt in je voorstel) doe maar...

performance : dat zal het probleem niet zo zijn denk ik

uptime : dat betekent dat je zowel de system als de data redundant moet uitvoeren

fouttolerantie : voor data kom je vrij snel op raid 5 omdat je anders teveel diskruimte weggooit en dat is in verhouding duurder als je moet uitbreiden (los van het feit of dat moet of niet)

Anyway, maak een netjes voorstel op papier, zet daar alle motivatie en overwegingen op en laat je baas kiezen....

[deDorus]

Wolvie schreef op 20 februari 2004 @ 11:50:
Dat ben ik niet helemaal met je eens. Ik zou wel de swapfile apart plaatsen van het OS en de database. Ik zou het OS mirroren en de database raid 5.

Ik scheef niet voor niets 'in dit geval', zoals de poster zelf al aangaf, er zijn maar 4 schijven.

[Femme]

Ideaal zou zijn 2 schijven in RAID 1 voor boot, drie in RAID 5 voor data en nog een hotspare erbij. Met vier schijven zou je RAID 5 + hotspare kunnen doen. Alles op één array kan voldoende performance geven, ligt eraan wat de eisen zijn en wat voor harde schijven en RAID-adapter er gebruikt gaan worden.

[Verwijderd]

RAID 5 is leuk als je de HD kan hotswappen maar mag je maar 1HD utval hebben.
2x RAID1 dan heb je 50% parity en mag de HD met de db en het OS uitvallen.
RAID 10 is ook leuk, stripped en mirrored.

Ik zou opteren voor 2x RAID1 of RAID10 in dit geval. Als de HD's van dezelfde partij zijn en als je een iets wat mindere partij hebt dan ben je het haasje.

[Verwijderd]

Verwijderd schreef op 20 februari 2004 @ 13:25:
RAID 5 is leuk als je de HD kan hotswappen maar mag je maar 1HD utval hebben.
2x RAID1 dan heb je 50% parity en mag de HD met de db en het OS uitvallen.
RAID 10 is ook leuk, stripped en mirrored.

Ik zou opteren voor 2x RAID1 of RAID10 in dit geval. Als de HD's van dezelfde partij zijn en als je een iets wat mindere partij hebt dan ben je het haasje.

Ik denk, dat we nu dus maar gewoon moeten kiezen voor 2x RAID1. De situatie die dan ontstaat moet zeker mee kunnen, totdat het netwerk hier een grote upgrade gaat krijgen. Dit is over hooguit een klein jaar, dus tot die tijd moeten we het hier maar mee doen.

Het gaat trouwens om 4 U320 SCSI-schijven (10.000 rpm) op een IBM RAID5i controller. De machine waarop het geheel gaat draaien is een dual Xeon (512 kB, 533 MHz) met 2,5 GB RAM.

[Verwijderd]

Verwijderd schreef op 20 februari 2004 @ 13:25:
RAID 5 is leuk als je de HD kan hotswappen maar mag je maar 1HD utval hebben.
2x RAID1 dan heb je 50% parity en mag de HD met de db en het OS uitvallen.
RAID 10 is ook leuk, stripped en mirrored.

Ik zou opteren voor 2x RAID1 of RAID10 in dit geval. Als de HD's van dezelfde partij zijn en als je een iets wat mindere partij hebt dan ben je het haasje.

reken eens uit hoeveel je dan wel niet kwijt bent aan partity met raid 10

[redfoxert]

Ik zou er nog 2 schijven bij laten komen en dan de volgende configuratie inrichten :

2 schijven in RAID1 voor het OS
3 schijven in RAID5 voor de database
1 schijf voor de transaction logs en je swapfile.

In totaal dus 6 discs. Eventueel kan je nog een hotspare erbij nemen, dan heb je er 7 nodig.

Redundant en de meest snelle oplossing. Overigens wel je swapfile op een fixed aantal mb's zetten om swapfile-fragmentatie te voorkomen.

[ Voor 10% gewijzigd door redfoxert op 20-02-2004 14:04 ]

[Femme]

Ik kan me niet voorstellen dat een doos met 2,5GB RAM veel gaat swappen zolang de database-server goed is geconfigureerd (die gebruikt neem ik aan een vaste maximale hoeveelheid geheugen met de rest vrij voor OS en diskcache). Swap en boot apart lijkt me wat overdreven.

[Verwijderd]

Femme schreef op 20 februari 2004 @ 14:21:
Ik kan me niet voorstellen dat een doos met 2,5GB RAM veel gaat swappen zolang de database-server goed is geconfigureerd (die gebruikt neem ik aan een vaste maximale hoeveelheid geheugen met de rest vrij voor OS en diskcache). Swap en boot apart lijkt me wat overdreven.

Wat heb jij er nou voor verstand van !!!

(hahahaha, dit is een grapje natuurlijk... kon het ff niet laten )

[Verwijderd]

Femme schreef op 20 februari 2004 @ 14:21:
Ik kan me niet voorstellen dat een doos met 2,5GB RAM veel gaat swappen zolang de database-server goed is geconfigureerd (die gebruikt neem ik aan een vaste maximale hoeveelheid geheugen met de rest vrij voor OS en diskcache). Swap en boot apart lijkt me wat overdreven.

Klopt.

[Verwijderd]

Verwijderd schreef op 20 februari 2004 @ 18:02:
[...]

Klopt.

Nee, het klopt niet... Want het is een mening.
Maar je kan het natuurlijk wel met de mening eens zijn

[redfoxert]

Femme schreef op 20 februari 2004 @ 14:21:
Ik kan me niet voorstellen dat een doos met 2,5GB RAM veel gaat swappen zolang de database-server goed is geconfigureerd (die gebruikt neem ik aan een vaste maximale hoeveelheid geheugen met de rest vrij voor OS en diskcache). Swap en boot apart lijkt me wat overdreven.

Swapfile kan je inderdaad ook wel op de OS disk laten staan maar dan heb je alsnog die extra disk nodig voor de transaction logs. Een goed geconfigde bak zou inderdaad gewoon alleen maar geheugen moeten gebruiken en geen swapfile maar in de praktijk komt het vaak toch anders voor.

[Verwijderd]

Verwijderd schreef op 20 februari 2004 @ 21:52:
[...]


Nee, het klopt niet... Want het is een mening.
Maar je kan het natuurlijk wel met de mening eens zijn

Dat de database-server een vaste hoeveelheid RAM toegewezen krijgt......

[Verwijderd]

FF Opletten, er zijn databases die niet goed presteren op een raid-5 configuratie, voorals als er veel 'geschreven' wordt in de database.

Hier een artikel (is wat gedateerd) over bv. een Progress database met raid5:
http://www.peg.com/techpapers/monographs/raid/raid.html

stukje over Sql Server:
http://www.databasejourna...mssql/article.php/1460091

Algemeen linkje:
http://www.bolthole.com/uuala/RAID.html

[ Voor 74% gewijzigd door Verwijderd op 24-02-2004 18:36 ]

[Verwijderd]

Mocht je geen diskje bij kunnen / mogen krijgen, 2xmirror.

Anders 1 diskje erbij (liefst 2) os mirror en db raid 5.
Mocht er een schijf klappen in de raid 5, verbreek je de mirror en gebruikt die disk en laat een nieuwe aanrukken die je weer in de mirror zet.

[Femme]

Verwijderd schreef op 24 februari 2004 @ 17:50:
FF Opletten, er zijn databases die niet goed presteren op een raid-5 configuratie, voorals als er veel 'geschreven' wordt in de database.

Hier een artikel (is wat gedateerd) over bv. een Progress database met raid5:
http://www.peg.com/techpapers/monographs/raid/raid.html

stukje over Sql Server:
http://www.databasejourna...mssql/article.php/1460091

Algemeen linkje:
http://www.bolthole.com/uuala/RAID.html

De write performance van RAID 5 hangt nogal af van de RAID-adapter. Als je een moderne adapter hebt zoals een HP Smart Array 6402, LSI MegaRAID SCSI 320-2X of Intel SRCU42X, kun je een hele behoorlijke performance halen in RAID 5.

Verder hangt veel af van de specifieke toepassing. RAID 10 met vier of zes schijven is wellicht wat sneller. Mijn ervaring is wel dat veel RAID-adapters niet al te efficient met spanning (RAID 10 en RAID 50) omgaan. Daardoor is het prestatieverschil tussen RAID 10 en RAID met vier schijven op veel adapters minimaal.

[Verwijderd]

Femme schreef op 25 februari 2004 @ 02:16:
[...]
De write performance van RAID 5 hangt nogal af van de RAID-adapter. Als je een moderne adapter hebt zoals een HP Smart Array 6402, LSI MegaRAID SCSI 320-2X of Intel SRCU42X, kun je een hele behoorlijke performance halen in RAID 5.

ah, zou goed kunnen, ik heb dit soort zaken zelf nooit getest, heb je misschien linkje naar benchmarks (met databases danwel)?