Storage configuratie

[Verwijderd]

Volgend vraagstuk.

Stel ik heb een storage waar ik meerdere applicaties/systemen op ga connecteren. Denk hierbij bijvoorbeeld aan een MSA500/1000 van HP of MD3000 van Dell.

Hierop connecteer ik een of meerdere servers. Manier waarop speelt geen rol (SAS, (i)SCSI, ...)

Nu wil ik verschillende applicaties gaan gebruiken en moeten de disken uiteraard goed ingericht worden.

Laten we even van het volgende voorbeeld uitgaan:
- SQL: DB op RAID1 volume, LOG op RAID1 volume
- Exchange: DB op RAID1 volume, LOG op RAID1 volume
- Fileserver: Data op RAID5 volume
- Backup: Backups op RAID5 volume

Deze functies draaien verdeeld op de servers (al dan niet virtueel). Nu moeten ze allemaal hun eigen LUNs hebben. Stel we hebben 20 schijven tot onze beschikking (allemaal even groot en even snel voor de gemakkelijkheid).


Nu kan je 'klassiek' gaan denken en elk volume op z'n eigen disken gaan zetten. Dus voor SQL DB 2 disken in RAID1, voor SQL Log 2 disken in RAID1, voor Fileserver 4 disken in RAID5 enz.

Voordelen:
- Elke LUN (volume) staat op z'n eigen disken en kan niet beinvloed worden door activiteit op andere LUN's
- Lage accesstime omdat de disken enkel de IO's van die LUN moeten doen.

Nadelen:
- Weinig IOPS omdat je LUN maar over weinig disken verdeeld staat
- Capaciteit moet je een beetje schikken naar je fysische disken


Je kan ook 'virtueel' gaan denken en elk volume (elke LUN dus) gaan verdelen over ALLE fysische disken. Dus SQL DB's in RAID10 over 20 disken, SQL Logs in RAID10 over diezelfde 20 disken, Fileserver in RAID5 over diezelfde 20 disken, enz.

Voordelen:
- Maximale IOPS omdat je LUN alle fysische disken kan gebruiken
- Capaciteit kan je gemakkelijk benutten omdat je minder rekening moet houden met de grootte van je fysische disken/RAID level

Nadelen:
- LUNs zijn beinvloedbaar door andere LUNs. Stel veel IO naar SQLDB, dan zal Exchange DB ook minder IO's krijgen omdat het onderliggend dezelfde disken zijn.
- Hogere accesstime. De kans is groter dat je fysische disken al bezig zijn met IO van andere LUNs.


Beide systemen hebben hun voor en nadelen. Het 'virtuele' model lijkt me zeer goed voor random IO, maar dan weer minder voor sequentiele IO (SQL logs, backups, ...). Het 'klassieke' model is zeker ook bruikbaar, maar lijkt me op vlak van performance zeker niet het beste voor random IO.

Grote Storagesystemen zoals een HP EVA werken grotendeels volgens het 'virtuele' principe, maar ik vraag me af in hoeverre dit ook bruikbaar is op de kleinere storages genre MSA (HP) of MD (Dell).

Wat denken jullie over beide manieren van werken?

[bitwizz]

De verschillen zijn imo groter dan je beschijft. Het 'virtual' aanbieden zoals je zelf zegt gaat op de kleinere diskcontrolers niet.
Ter vergelijking tussen een MSA en een EVA:

MSA
Voordelen:

• Lage instap prijs
• Lage drempel om te starten, omdat het wordt beheerd met ACU
• De zelfde disks worden gebruikt al die in een server.

Nadeel:

• Bij uitval van een disk moet deze vervangen worden om weer redudant te zijn (al is het met een Hot spare).
• Niet gemakkelijk om een LUN uit te breiden. en als je meerdere LUNs op een disk groep heb zitten is alleen de laatste die aangemaakt is uitgebreid worden.
• bij redudant controlers worden de voedingen en ombouw gedeeld.
• mocht het zijn dat er op een disk veel gelezen en geschreven wordt al dit te nadelen zijn van je totale snelheid. terwijl andere disks grote delen vand dag staat te rusten.

EVA
voordelen:

• Gemakelijk om een LUN te vergroten ongeacht of deze als eerste aangemaakt is of als laatste.
• Volledige redudant. zowel de controlers al de aansluitingen zijn dubbel of meer uitgevoerd. ieder controler heeft zijn eigen voeding
• Er wordt zonder verlies van prestatie gelijk redudantie terug opgebouwd.
• Disk belasting in de zin van hoevaak word data van een disk aangeproken en weggeschreven wordt door een EVA over alle disks geprobeerd te verspreiden zodat alle disks even veel aanvragen hebben om dat te schrijven of lezen

Nadelen:

• Beheer wordt met een tool uitgevoerd worden waar best aangewend moet worden.
• Geen standaard disks (het zijn Fibel SCSI disks).
• hoge start kosten.

Uit ervaring weet ik dat een EVA met 20 disks vele malen sneler zijn dan een MSA met 20 disks.
Laat je voor dat je over gaat tot aanschaf goed informeren en kijk ook goed rond naar andere partijen. Mijn ervaring is dat je vooral van te voren moet weten wat je eisen en wensen zijn, zoals:

• Hoeveel IOPS verwacht ik per soort server.
• Wat is je begroting.
• moet je rekening houden dat opslag in de toekomst anders kan gaan groeien dan je nu kan verwachten (door bijvoorbeeld fusies of overnames)

Ik vergelijk hier het HP matriaal om dat ik er ervaring mee heb.
Als je kunt verandwoorden dat een midden grote diskcontroler zou willen aanschaffen. Zou ik daar voor gaan. de TCO wordt gelang de tijd van een midden grote versie beter. Omdat de support langer door zal gaan en makkelijker met je organisatie mee kan groeien. Met veel minder werk.

[Verwijderd]

Alvast bedankt voor je antwoord.

Het is op zich geen keuze tussen een MSA (entry level) & EVA (enterprise) of MD & CX storage. Dat is tenslotte appelen met peren vergelijken.

Het gaat hem eerder om de manier van de LUN's configureren op de entry level storages voor kleinere locaties.

Bij mijn weten kun je op een MSA toch 1 grote RAID array maken van al je fysische disks en daar dan meerdere logische disks op aanmaken met verschillende RAID levels? Het extenden van disken is wel een nadeel aan deze manier dan, maar vraag me toch af het een meerwaarde bied tov de klassieke opzet in de praktijk.

[bitwizz]

Het klopt dat je met een MSA een grote diskgroep kunt aanmaken. Maar de kans dat er 2 schijven vlak achter elkaar defect gaan is met 20 schijven redelijk aanwezig. Waardoor je RAID5 gegevens verloren gaan. Als ik het zo even uit mijn hoofd moet zeggen zal HP ACU zelf een waarschuwing op het moment dat je meer dan 10 disks in 1 disk groep zet. En als meer dan 16 disks in één goep zet zal er zelfs een error komen dat HP geen beschikbaarheid garantie geeft. Helaas kan ik zo de pdf niet vinden waar alle ACU meldingen worden vermeld.

Maar de waarschuwing heb ik tot spijt als eens genegeerd. Gelukkig op een backup systeem en geen pruductie. Maar als er 1 disk tussen uit knijpt zal er vrij vlot een tweede mee gaan. En hoe groter de diskgroep is, hoe langer het duurt voor dat de gegevens weer redudant zijn. Met de Diskgoep van 32 disks toe bleek al snel dat we die tijd niet hadden. Met als gevolg dat de hele RAID 5 set verloren is gegaan. Maar we hebben zweten dat aub er geen gebuiker kwam met de vraag om een bestand van de vorige dag terug te zetten.

Daarom zou ik je niet advieseren om al je disks in een diskgroep te zetten. Maar deze te verdelen in blokken van maximaal van 8 schijven. Hierop kan je dan je LUNs aanmaken. Nadeel is wel dat je een stuk minder flexibel bent.

Een EVA werk intern ook met kleinere sets waar over RAID 5 infromatie over verspeid wordt.

in het geval als je 20 disks gebruikt zal een EVA intern 2 groepen van 7 schijven aanmaken en 1 groep van 6 schijven (deze heten RRS sets). binnen een zo'n set wordt er gezorg dat alle data redudant beschikbaar is. een LUN is vervolgens over die 3 sets verpreid voor snelheid. Daarom wordt binnen een EVA niet geproken over RAID5 maar VRAID5. Omdat er meer dan 1 disk wordt gebuikt voor redudantie.

[thund3rball]

het verhaal van Bitwizz klopt, echter 1 kanttekening.

vorige week met een msa1000 bezig geweest, heeft ook de mogelijkheid van raid6. Hierdoor kunnen er twee disks sneuvelen uit een set, zonder dat je een probleem hebt (wel snel vervangen :-)). Geeft je de mogelijkheid om alle disken in één (raid6) set te plaatsen, zonder dat je het zweet gaat uitbreken bij één defecte disk.

de performance van een msa is echter niet geweldig, als je echt performance nodig hebt, ga dan voor een eva of vergelijkbaar iets...

[SpamLame]

Ook ik wil een opmerking maken, maar over het EVA stukje van Bitwizz.

Hoewel het mogelijk is om een diskgroup te maken van 20 disken, raad HP in zijn best practices aan
om disken te groeperen in een veelvoud van 8. Dit heeft te maken met de voorkeur de EVA om RS sets (afkorting is van RSS= Redundant Storage Set) van 8 te bouwen, waarbij bij diskuitval de sets dus kunnen wijzigen. Lees de best practices of whitepapers van je voorkeurs apparaat door en laat je goed informeren door bv. je preferred supplier en een concurent

Verder zou ik je aanraden om in geval van een MSA te kijken naar de 1500 lijn.
Heb je iets meer keuze in connectiviteit en schijven die je eronder kunt hangen.
Maar ook hier geld, zorg dat je weet wat je zoek (in getallen zoals Bitwizz al aangeeft) en laat
je goed informeren en inlezen.

[ Voor 22% gewijzigd door SpamLame op 21-09-2007 15:15 ]

[bitwizz]

SpamLame schreef op vrijdag 21 september 2007 @ 15:12:
Ook ik wil een opmerking maken, maar over het EVA stukje van Bitwizz.

Hoewel het mogelijk is om een diskgroup te maken van 20 disken, raad HP in zijn best practices aan
om disken te groeperen in een veelvoud van 8. Dit heeft te maken met de voorkeur de EVA om RS sets (afkorting is van RSS= Redundant Storage Set) van 8 te bouwen, waarbij bij diskuitval de sets dus kunnen wijzigen. Lees de best practices of whitepapers van je voorkeurs apparaat door en laat je goed informeren door bv. je preferred supplier en een concurent

Het advies van HP is mij heel goed bekend. Maar in het verhaal van de topicstarter wordt er vanuit gegaan dat hij 20 schijven wilt gaan gebruiken. HP advieseerd zelfs om minimaal 8 enclosures te gebruiken als er gebruikt gemaakt gaat worden van VRAID5. Dit om uitval verkomen als er één enclosure defect gaat.

[Verwijderd]

Het aantal schijven en aantal applicaties was maar puur fictief opgegeven.

Het gaat me gewoon om het verschil tussen elke LUN op aparte RAID sets te zetten of deze samen te groepen.

Stel op een MSA reeks:

je wil SQL of Exchange DB's & Logs op je MSA plaatsen en je hebt 8 disken.

Of:
- je DB's komen op 6 disken in RAID 10 & je logs op 2 disken in RAID1
- je DB's komen op het grootste stuk van de 8 disken in RAID10 & je logs op een kleiner stuks in RAID1

In het eerste geval het je het voordeel dat je log-disken zich enkel met sequentiele write-io's moeten bezighouden (lage accesstime dus) en in het tweede geval heb je het voordeel dat je DB's hogere IOPS kunnen halen door het grotere aantal disken.


Uiteraard moet zoiets in de praktijk grondig getest worden maar ik wou gewoon jullie meningen eens weten over beide manieren van configureren.