Alignen van LVM en filesystem op hardware RAID (raid10)

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • Gertjan
  • Registratie: Oktober 2001
  • Laatst online: 09-09 17:11

Gertjan

mmmm, beer...

Topicstarter
Ik ben aan het spelen met storage voor een nieuwe databaseserver. Ik lees (veel) verschillende verhalen en meningen over het alignen van filesystems op de onderliggende storage, maar ik kan geen sluitende uitleg hierover vinden. Daarom leg ik de situatie hier aan de experts voor :).

Hardware: Dell R610 met 6 disks in hardware raid, die in RAID-10 geconfigureerd zijn. Dit levert dus een stripe van 3 disks op. Bij wijze van test heb ik gekozen voor een stripe size van 512 kB. Om de complexiteit minder groot te maken heb ik ervoor gekozen om geen partities te gebruiken, maar de disk, /dev/sdb, direct als een physical volume voor LVM te gebruiken. Daarboven op moet een XFS-filesystem komen.

In deze blogpost wordt volgens mij een goede uitleg gegeven van de materie, met een boel verwijzingen naar andere discussies.

Onder het kopje 'Steps to setup LVM' staat bij stap 2:
Normally the LVM metadata allocates 196kB (we need to allocate a little more for alignment)

pvcreate --metadatasize 250k /dev/md0 (apparently the calculation is 250KiB *1.024=256, what a mess...)

To verify:
pvs -o +pe_start
Als ik dit toepas op mijn situatie (RAID-10, 6 disks = 3 stripes, stripe size 512kB), betekent dat volgens mij dat ik pvcreate moet vertellen dat hij zo'n grote metadatasize moet nemen, dat het binnen 1 stripe past:

root@db16 ~ # pvcreate --metadatasize 500k /dev/sdb
  Physical volume "/dev/sdb" successfully created
root@db16 ~ # pvs -o +pe_start
  PV         VG   Fmt  Attr PSize   PFree   1st PE 
  /dev/sdb        lvm2 --   208.37G 208.37G 512.00K


Dit lijkt goed te zijn. Nu kom ik echter bij stap 3, waarbij ik een volume group maak die ge-aligned moet zijn op dit physical volume, door de juiste physicalextendsize te kiezen.
This needs to align on top of the md layer. So it has to be a multiple of 256Kib

It can be argued that it is beneficial to have it a multiple of
256Kib*4=1MiB (where 4:Raid Devices-1).
In mijn geval zou de physicalextentsize worden: 512 * 3 = 1.5 MiB. Volgens de manpage van vgcreate moet de physicalextendsize echter een macht van 2 zijn, en dat is niet mogelijk met 1.5.

Ik ga met mijn redenatie ergens de mist in, maar kan iemand me uitleggen waar? Is het uberhaupt nodig om RAID-10 op deze manier te alignen?

Acties:
  • 0 Henk 'm!

  • Gertjan
  • Registratie: Oktober 2001
  • Laatst online: 09-09 17:11

Gertjan

mmmm, beer...

Topicstarter
Niemand hier die iets weet over het alignen van filesystems? :'(

Acties:
  • 0 Henk 'm!

Verwijderd

Gertjan schreef op maandag 14 juni 2010 @ 13:17:
[...]

Dit lijkt goed te zijn. Nu kom ik echter bij stap 3, waarbij ik een volume group maak die ge-aligned moet zijn op dit physical volume, door de juiste physicalextendsize te kiezen.

[...]

In mijn geval zou de physicalextentsize worden: 512 * 3 = 1.5 MiB. Volgens de manpage van vgcreate moet de physicalextendsize echter een macht van 2 zijn, en dat is niet mogelijk met 1.5.
Het zou kunnen zijn dat ik je verkeerd begrijp, maar waar haal je de '3' vandaan in 512 * 3 = 1.5MiB? Volgens het artikel dat je citeert moet dat het aantal RAID-disks zijn, minus 1. Ik heb het artikel niet gelezen, maar ik zou denken dat de '3' ofwel '2' (numstripes - 1), ofwel '5' (numdisks - 1) moet zijn?

Acties:
  • 0 Henk 'm!

  • Tout
  • Registratie: Mei 2006
  • Laatst online: 09-06-2022
Volgens mij gaat je redenatie mis, omdat het artikel geënt is op raid5. Bij raid5 heb je volgens mij altijd een oneven aantal disks.

Verderop staat er in het artikel (weliswaar onder een ander kopje):

Here for RAID5: width=su*(number of Raid Drives - 1)
for RAID 6, it would be: width=su*(number of Raid Drives -2)

Ik zou eens kijken naar een soortgelijk artikel voor raid10.

Acties:
  • 0 Henk 'm!

  • Boudewijn
  • Registratie: Februari 2004
  • Niet online

Boudewijn

omdat het kan

Tout schreef op donderdag 17 juni 2010 @ 17:20:
Volgens mij gaat je redenatie mis, omdat het artikel geënt is op raid5. Bij raid5 heb je volgens mij altijd een oneven aantal disks.
Nee hoor, zij bijvoorbeeld:

Wikipedia: Redundant Array of Independent Disks

i3 + moederbord + geheugen kopen?


Acties:
  • 0 Henk 'm!

  • Gertjan
  • Registratie: Oktober 2001
  • Laatst online: 09-09 17:11

Gertjan

mmmm, beer...

Topicstarter
Tout schreef op donderdag 17 juni 2010 @ 17:20:
Volgens mij gaat je redenatie mis, omdat het artikel geënt is op raid5. Bij raid5 heb je volgens mij altijd een oneven aantal disks.
Nee hoor, je kunt RAID 5 met elk aantal disks doen dat je wil, mits je er minimaal 3 hebt. Volgens mij zou dit artikel ook prima op RAID 10 toepasbaar moeten zijn, omdat het uitgaat van een RAID-level dat striped. Dat betekent bijvoorbeeld RAID 5, maar ook RAID 0, en dus ook RAID 10. Op RAID 1 is het niet toepasbaar, omdat daar niet bij gestriped wordt.
Verwijderd schreef op donderdag 17 juni 2010 @ 16:24:
[...]

Het zou kunnen zijn dat ik je verkeerd begrijp, maar waar haal je de '3' vandaan in 512 * 3 = 1.5MiB? Volgens het artikel dat je citeert moet dat het aantal RAID-disks zijn, minus 1. Ik heb het artikel niet gelezen, maar ik zou denken dat de '3' ofwel '2' (numstripes - 1), ofwel '5' (numdisks - 1) moet zijn?
Ik heb een RAID 10 van 6 disks, wat betekent dat er RAID 0 gestriped wordt over 3 paartjes in RAID 1. In het voorbeeld wordt er uitgegaan van aantal disks minus 1, omdat er bij RAID 5 1 disk 'wegvalt' voor parity. Je filesysteem moet daar dus geen rekening mee houden, omdat hij die disk niet kan gebruiken. Bij RAID 0 (en RAID 10) zijn echter wel alle disks in je stripe bruikbaar voor het filesystem, dus in mijn geval kwam ik op drie uit.

Ik denk echter dat al snap waar ik met mijn redenatie mis ben gegaan. Ik ging ervan uit dat je de vgextendsize altijd dermate groot wil hebben, dat 1 extent even vaak gebruik maakt van elke disk. Dat is echter waarschijnlijk niet nodig, en is alleen in theoretische gevallen sneller en nodig. Vandaar dat er in het artikel ook staat:
It can be argued that it is beneficial to have it a multiple of
256Kib*4=1MiB (where 4:Raid Devices-1).
Met deze kennis ben ik iets verder gaan experimenteren, en heb ook 32MB als physicalextentsize genomen. Voor XFS kwam de alignment dan volgens mij uit op su=512k,sw=3. Ik heb met enkele (OLTP) testjes echter nauwelijks performanceverbetering waar kunnen nemen.
Ik denk dat ik het er maar even bij laat, deze server moet live, en mijn baas zit niet te wachten op een wetenschappelijk onderbouwde performancewinst van 2% :). Wel jammer, want ik zou er graag meer mee experimenteren. Binnenkort even een nieuwe server kopen :).

Acties:
  • 0 Henk 'm!

  • Nielson
  • Registratie: Juni 2001
  • Laatst online: 13:07
XFS aligned toch al automatisch goed?

/edit: Beetje kortzichtig antwoord van me, aangezien het hier gaat om een complexe raidvorm en lvm er nog tussen.

[ Voor 62% gewijzigd door Nielson op 21-06-2010 15:08 ]


Acties:
  • 0 Henk 'm!

  • Gertjan
  • Registratie: Oktober 2001
  • Laatst online: 09-09 17:11

Gertjan

mmmm, beer...

Topicstarter
Nielson schreef op maandag 21 juni 2010 @ 15:01:
XFS aligned toch al automatisch goed?
Bij software RAID inderdaad wel, omdat XFS de benodigde informatie dan uit de md-driver van Linux kan halen. Bij hardware RAID kan dat echter niet, omdat het voor het OS niet zichtbaar is hoeveel schijven eronder hangen.
Pagina: 1