Striping op een SAN

[d00d]

Op onze productie SQL Server maken we gebruik van een SAN (van IBM). Dit zorgt voor een snelle IO. Nu is ervoor gekozen om ook nog eens gebruik te maken van disk striping binnen windows (2003 EE). Ik kan nog wel beredeneren dat striping voor een betere performance zorgt omdat de data wordt gelezen en geschreven over meerdere controllers, maar geldt dit ook nog binnen een SAN?

Meten is weten, maar helaas is het niet zo eenvoudig om te gaan "knutselen" op de productie machine.

Het nadeel van deze oplossing is dat iedere keer dat ik extra schijfruimte wil, er ook een nieuwe drive letter wordt aangemaakt, terwijl ik liever zie dat een bestaande partitie wordt uitgebreid.

Mijn vraag is dus, kan iemand logisch beredeneren waarom striping op een SAN goed/slecht is. Je hoeft geen rekening te houden met mijn gevoelens, de situatie was al zo toen ik werd aangenomen

[KatirZan]

een goede eigenschap van SAN is dat je niet gebonden zit aan een bepaalde grootte per schijf....

een OS schijf hoeft niet groter te zijn dan 16gb, een program schijf daarentegen..... en dan heb je nog een standaard data schijf...

een goed gebruik van SAN vergt flink wat rekenwerk en toekomst inzicht, dat is wel een nadeel als je "snel eventjes wat schijfruimte nodig hebt"

dat is trouwens zowiezo niet zo'n goede instelling bij een server elk stukje software wat je installeerd op een server heeft een functie...en bij die functie moet worden nagedacht

[Hardware Junk]

Daniël, kan je even contact op nemen per e-mail?

[d00d]

KatirZan schreef op dinsdag 16 januari 2007 @ 11:58:
dat is trouwens zowiezo niet zo'n goede instelling bij een server elk stukje software wat je installeerd op een server heeft een functie...en bij die functie moet worden nagedacht

Er is vast goed over nagedacht, ik heb alleen het gevoel dat de verkeerde conclusie is getrokken...

[JoostdeGraaf]

Het lijkt mij niet verstandig. Het leverd meer CPU belasting op, maar de IO gaat nog steeds naar dezelfde schijven. De IO actie wordt niet over meer fysiek schijven uitgesmeerd waardoor het sneller wordt.

[Verwijderd]

Striping is inderdaad alleen nuttig om de data over meer fysieke schijven te verdelen en daarmee snelheid te winnen. Een SAN doet dat normaal gesproken zelf al met een RAID variant. Als je daar dan volumes op definieert die uitgesmeerd worden over de raid array en die samen stripet levert het geen winst op, alleen extra overhead qua CPU en disk IO (omdat elk stukje data door de CPU in 3 wordt gesplitst en als 3 IOs bij het SAN aankomt ipv 1).

Stel dus het is een RAID set van 8 schijven in het SAN en alle volumes/LUNs op het SAN worden gelijkelijk erover uitgesmeerd. Normaal gesproken wordt 1 grote IO actie gestuurd door windows naar het volume. Dat wordt dan op het SAN in een veelvoud van 8 gesplitst naar gelang de stripe size. (parity buiten beschouwing gelaten). Omdat alle 8 schijven tegelijk aan het werk gaan, is dat zo snel.

Als je dan 3 volumes striped binnen windows met software raid, gebeurt het volgende: Windows splitst de 1 grote IO in stukken volgens de stripe size. Dat kunnen er 3, 6, 30 of 300 zijn. (Ik weet niet of Windows de stukjes voor 1 volume weer als 1 IO doorstuurt) Die worden dan naar de 3 volumes gestuurd. Daar worden al die stukjes weer in 8 gesplitst.
In het gunstigste geval heb je dus de CPU die moet werken om 3 IOs ipv 1 naar het SAN te sturen en het SAN dat er 3 keer zoveel moet verwerken. Als Windows het niet in de cache houdt en elke stukje stripe apart wegschrijft naar disk kan het nog veel erger worden.

Wat ik in je overzicht ook zie is dat één van de drie volumes die gestriped zijn veel groter is dan de andere. Dat is ook erg onhandig. Of je bent de extra ruimte kwijt, of de performance kwijt voor alles boven de 300 GB.

edit:
Niet goed gekeken, het zijn aparte stripes.

Ik zou kijken of je de stripes kunt vervangen door niet gestripe-de volumes. Die kun je als het goed is ook gewoon vergroten (hangt af van IBM software), zelfs online. Maar wel even testen

[ Voor 45% gewijzigd door Verwijderd op 16-01-2007 17:02 ]