LVM vs mdadm voor zware server

[Verwijderd]

Voor een redelijk zware server (oct core, 48GB memory, 2xAreca 1680+4GB, 16 Mtron 7535 SSD's) die we aan het opzetten zijn, is het nodig dat we gebruik maken van software RAID 0.

Deze software RAID 0 bestaat uit 2 devices, die elk een RAID 5 zijn van 8 SSD's op 1 Areca RAID controller. Dit is noodzakelijk omdat 1 enkele Areca (met een 1.2GHz IOP) aantoonbaar niet voldoende performance heeft om 16 SSD's te benutten.

Voor de software RAID zien we 2 mogelijkheden: mdadm of LVM-striping.

mdadm hebben we getest en werk super goed. De performance is significant beter. Het grote probleem met mdadm is echter dat de systeembeheerder hier iets op tegen heeft. Hij is een grote aanhanger van LVM. We zijn dus ook met LVM gaan testen, echter deze leverde wat problemen op. Bij b.v. het draaien van de bekende easyco benchmark zie je heel duidelijk dat bij bepaalde block sizes er hele stukken missen: de performance zakt dan totaal in elkaar. Dit was voornamelijk zichtbaar bij de writes.

Na even nazoeken blijkt dat de door ons gebruikte LVM 2.02.39-6 uit Debian Lenny (testing) diverse problemen heeft met allignment, inderdaad bij bepaalde block sizes. Dit is natuurlijk erg vervelend. Nieuwere versies van LVM zouden dit naar verluid niet meer hebben, echter omdat we op Debian draaien is dat geen optie. Zelfs Debian unstable bevat die 2.02.39-6, dus de kans dat er op hele korte termijn een nieuwere versie in Debian testing komt, laat staan stable lijkt me nihil.

De grote vraag is dus, is mdadm inderdaad iets wat onbetrouwbaar is en vermeden moet worden? Ik ben zelf geen systeem beheerder (maar developer) en kan deze afweging dus niet helemaal maken. Wie weet meer?

[DGTL_Magician]

Persoonlijk zou ik deze discussie uberhaupt niet willen voeren en gewoon voor een hardware oplossing gaan. Software RAID is imho toch meer een hobby oplossing en zeker niet inzetbaar voor zware productie servers.

[axis]

Al gekeken naar ZFS (op FreeBSD/Solaris), of ben je gebonden aan linux? (Ik heb al jaren geen linux meer aangeraakt, dus daar ik kan ik niets over zeggen)

Daarnaast heb je een grote kans dat je met jouw configuratie als je helemaal software RAID gebruikt (dus software RAID50 over de 16 disks, en de Areca's in JBOD) een nog hogere performance haalt dan HW RAID5+SW RAID0. Maar daar zou je vrij snel achter moeten kunnen komen met wat testjes.


leuk: http://forums.overclockers.com.au/showthread.php?t=567574 (niet vergelijkbaar met je dure enterprise stuff, maar wel leuk om te zien hoe ZFS kont schopt.)

[ Voor 15% gewijzigd door axis op 22-01-2009 16:28 ]

[Verwijderd]

DGTL_Magician schreef op donderdag 22 januari 2009 @ 16:12:
Persoonlijk zou ik deze discussie uberhaupt niet willen voeren en gewoon voor een hardware oplossing gaan. Software RAID is imho toch meer een hobby oplossing en zeker niet inzetbaar voor zware productie servers.

pfff krijgen we deze discussie weer, die is ook al 100 keer gevoerd. Dit is gewoon onzin... Beide oplossingen (software- of hardware raid) hebben zo hun eigen voordelen en nadelen, dit zal iedereen zelf moeten afwegen.

En ja mdadm is betrouwbaar.

En zoals axis al zei, is ZFS een hele goede oplossing.

[ Voor 7% gewijzigd door Verwijderd op 22-01-2009 16:18 ]

[mph_rbi]

Inderdaad is dat een onzindiscussie.. Wij draaien met meerdere MSA60 raid enclosures in RAID6 met z'n allen gekoppeld in LVM tot 1 stripe.

Het is 2009 DGTL_Magician

[_Arthur]

DGTL_Magician schreef op donderdag 22 januari 2009 @ 16:12:
Persoonlijk zou ik deze discussie uberhaupt niet willen voeren en gewoon voor een hardware oplossing gaan. Software RAID is imho toch meer een hobby oplossing en zeker niet inzetbaar voor zware productie servers.

Waar denk je dat deze 'hardware controllers' mee werken intern? Ook gewoon software hoor

[gertvdijk]

@DGTL_Magician: verwar de fakeraid controllers niet met mdadm!

@TS: je post bevat volgens mij voldoende argumenten voor je systeembeheerder om hem eens te laten kijken naar mdadm. Als je zelf LVM gaat lopen compilen of zelfs overstapt op een andere distro heb je er meer werk aan, vrees ik. Daarnaast kan je natuurlijk LVM nog wel blijven gebruiken voor andere doeleinden, bovenop de mdadm array.

[ Voor 15% gewijzigd door gertvdijk op 22-01-2009 17:58 ]

[Verwijderd]

_Arthur schreef op donderdag 22 januari 2009 @ 17:50:
[...]

Waar denk je dat deze 'hardware controllers' mee werken intern? Ook gewoon software hoor

Handig. Weet je gelijk waar je geen IT-diensten af moet nemen. :-)

[Verwijderd]

axis schreef op donderdag 22 januari 2009 @ 16:15:
Al gekeken naar ZFS (op FreeBSD/Solaris), of ben je gebonden aan linux? (Ik heb al jaren geen linux meer aangeraakt, dus daar ik kan ik niets over zeggen)

Ik ben absoluut gebonden aan Linux, ZFS klinkt interesant maar is dus helaas geen optie.


De gaten in de performance waar ik eerder over melde blijker echter niet te wijten aan LVM, maar aan de RAID level die op de Areca gebruikt wordt. Bij de LVM test was er sprake van 2 hardware RAID 5's, terwijl bij mdadm eerder per ongeluk een RAID 0 was ingesteld.

Ter referentie, dit zijn de resultaten van 2x5 SSD's op 2 RAID controllers in RAID 0 via mdadm:

code:

/EasyCo# ./bm-flash /ssd/softraid/test.txt 

Filling 4G before testing  ...   4096 MB done in 1 seconds (4096 MB/sec).

Read Tests:

Block |   1 thread    |  10 threads   |  40 threads   
 Size |  IOPS    BW   |  IOPS    BW   |  IOPS    BW   
      |               |               |               
 512B | 27261   13.3M | 64476   31.4M | 63899   31.2M 
   1K | 34379   33.5M | 64453   62.9M | 63720   62.2M 
   2K | 33806   66.0M | 64298  125.5M | 63527  124.0M 
   4K | 32244  125.9M | 64179  250.7M | 63575  248.3M 
   8K | 29234  228.3M | 63473  495.8M | 62813  490.7M 
  16K | 24490  382.6M | 62030  969.2M | 61549  961.7M 
  32K | 18714  584.8M | 57469 1795.9M | 56509 1765.9M 
  64K | 12695  793.4M | 43219    2.6G | 43556    2.6G 
 128K | 11014 1376.8M | 21875    2.6G | 21872    2.6G 
 256K |  6676 1669.0M | 10978    2.6G | 10979    2.6G 
 512K |  3781 1890.5M |  5494    2.6G |  5501    2.6G 
   1M |  1972    1.9G |  2750    2.6G |  2753    2.6G 
   2M |  1093    2.1G |  1375    2.6G |  1376    2.6G 
   4M |   594    2.3G |   674    2.6G |   686    2.6G 

Write Tests:

Block |   1 thread    |  10 threads   |  40 threads   
 Size |  IOPS    BW   |  IOPS    BW   |  IOPS    BW   
      |               |               |               
 512B | 33248   16.2M | 32190   15.7M | 31686   15.4M 
   1K | 32128   31.3M | 31034   30.3M | 31113   30.3M 
   2K | 31783   62.0M | 30765   60.0M | 30624   59.8M 
   4K | 30393  118.7M | 29446  115.0M | 28974  113.1M 
   8K | 26376  206.0M | 25733  201.0M | 25032  195.5M 
  16K | 20776  324.6M | 19168  299.5M | 14011  218.9M 
  32K | 14100  440.6M | 10218  319.3M | 10838  338.6M 
  64K |  7373  460.8M |  6144  384.0M |  4842  302.6M 
 128K |  9376 1172.0M |  7334  916.7M |  3965  495.6M 
 256K |  2818  704.5M |  4585 1146.2M |  1961  490.2M 
 512K |  2340 1170.2M |  2776 1388.3M |  1362  681.2M 
   1M |   776  776.5M |   894  894.5M |  1618 1618.7M 
   2M |   466  933.1M |   635 1270.3M |   719 1438.3M 
   4M |   604    2.3G |   293 1174.7M |   252 1010.0M

edit:

en hier nog een setup met LVM raid 5 2x6 SSDs op 2 controllers:

code:

/EasyCo# ./bm-flash /ssd/ssd-striped/test.txt 

Filling 4G before testing  ...   4096 MB done in 1 seconds (4096 MB/sec).

Read Tests:

Block |   1 thread    |  10 threads   |  40 threads   
 Size |  IOPS    BW   |  IOPS    BW   |  IOPS    BW   
      |               |               |               
 512B | 21856   10.6M | 59945   29.2M | 59381   28.9M 
   1K | 32945   32.1M | 59773   58.3M | 59252   57.8M 
   2K | 32462   63.4M | 59611  116.4M | 59081  115.3M 
   4K | 31398  122.6M | 59707  233.2M | 58946  230.2M 
   8K | 28847  225.3M | 58294  455.4M | 57684  450.6M 
  16K | 24965  390.0M | 57934  905.2M | 57004  890.6M 
  32K | 19393  606.0M | 52848 1651.5M | 52520 1641.2M 
  64K | 13466  841.6M | 46626    2.8G | 46533    2.8G 
 128K |  8541 1067.6M | 25962    3.1G | 27364    3.3G 
 256K |  7777    1.8G | 13876    3.3G | 13876    3.3G 
 512K |  4377    2.1G |  6942    3.3G |  6943    3.3G 
   1M |  2356    2.3G |  3472    3.3G |  3473    3.3G 
   2M |  1292    2.5G |  1735    3.3G |  1732    3.3G 
   4M |   728    2.8G |   847    3.3G |   864    3.3G 

Write Tests:

Block |   1 thread    |  10 threads   |  40 threads   
 Size |  IOPS    BW   |  IOPS    BW   |  IOPS    BW   
      |               |               |               
 512B | 31208   15.2M | 30125   14.7M | 22332   10.9M 
   1K | 29351   28.6M | 29055   28.3M | 27419   26.7M 
   2K | 24413   47.6M | 28681   56.0M | 27832   54.3M 
   4K | 28874  112.7M | 25613  100.0M | 25060   97.8M 
   8K |    27  216.0K |   925    7.2M | 12215   95.4M 
  16K | 18230  284.8M | 20401  318.7M |    13  209.5K 
  32K | 12462  389.4M |    35 1148.7K | 13666  427.0M 
  64K |    10  684.7K |  8437  527.3M |     6  441.5K 
 128K |  7030  878.7M |     2  332.7K 
 256K |  4523 1130.8M |     3  947.1K 
 512K |  4222    2.0G |     5    2.5M 
   1M |  2085    2.0G |     2    2.0M 
   2M |  1495    2.9G |    12   25.1M 
   4M |   768    3.0G |   122  488.0M |   143  573.5M

Dat ziet er dus niet best uit. Echter, een vergelijking nogmaals met mdadm op een level 5 RAID leverde dus ook dat zelfde beeld op:

code:

/EasyCo# ./bm-flash /ssd/ssd-striped/test.txt 

Filling 4G before testing  ...   4096 MB done in 1 seconds (4096 MB/sec).

Read Tests:

Block |   1 thread    |  10 threads   |  40 threads   
 Size |  IOPS    BW   |  IOPS    BW   |  IOPS    BW   
      |               |               |               
 512B | 23051   11.2M | 64767   31.6M | 64178   31.3M 
   1K | 34798   33.9M | 64500   62.9M | 64027   62.5M 
   2K | 34265   66.9M | 64435  125.8M | 63937  124.8M 
   4K | 33080  129.2M | 64502  251.9M | 63724  248.9M 
   8K | 30159  235.6M | 63042  492.5M | 62262  486.4M 
  16K | 26010  406.4M | 62403  975.0M | 61926  967.5M 
  32K | 19961  623.7M | 56464 1764.5M | 55878 1746.2M 
  64K | 13773  860.8M | 48710    2.9G | 49230    3.0G 
 128K | 12369 1546.1M | 27712    3.3G | 27707    3.3G 
 256K |  7628 1907.2M | 13875    3.3G | 13875    3.3G 
 512K |  4345    2.1G |  6941    3.3G |  6942    3.3G 
   1M |  2347    2.2G |  3471    3.3G |  3472    3.3G 
   2M |  1331    2.5G |  1735    3.3G |  1733    3.3G 
   4M |   738    2.8G |   806    3.1G |   858    3.3G 

Write Tests:

Block |   1 thread    |  10 threads   |  40 threads   
 Size |  IOPS    BW   |  IOPS    BW   |  IOPS    BW   
      |               |               |               
 512B | 32130   15.6M | 28086   13.7M | 27515   13.4M 
   1K | 27969   27.3M | 29546   28.8M | 30940   30.2M 
   2K | 25502   49.8M | 28639   55.9M | 28592   55.8M 
   4K | 27826  108.6M | 27626  107.9M | 18681   72.9M 
   8K |    88  705.5K | 11655   91.0M |  4190   32.7M 
  16K | 17673  276.1M |  4720   73.7M |  8917  139.3M 
  32K | 12036  376.1M |    24  768.0K 
  64K |  8481  530.1M |     3  217.5K 
 128K |  7120  890.0M |     8 1139.1K 
 256K |  6267 1566.8M |     8    2.0M 
 512K |  4849    2.3G |     4    2.1M 
   1M |  2766    2.7G |   779  779.5M |   801  801.7M 
   2M |   396  792.3M |   499  998.1M |   514 1028.7M 
   4M |   298 1194.7M |   191  764.3M |   227  910.0M

(de laatste 2 testen hebben trouwens een hogere maximale read, omdat de kaarten nu in 2 PCI-E bussen zitten die allebei op de northbridge aangesloten zijn. De andere test was met 1 kaart op de southbridge en 1 kaart op de northbridge. Ik kan het test resultaat van "2x5 op 2 kaarten, RAID0, beiden kaarten in northbridge, mdadm" even niet meer vinden)

[ Voor 44% gewijzigd door Verwijderd op 23-01-2009 13:34 ]

[gertvdijk]

Verwijderd schreef op vrijdag 23 januari 2009 @ 13:13:
Dat ziet er dus niet best uit. Echter, een vergelijking nogmaals met mdadm op een level 5 RAID leverde dus ook dat zelfde beeld op:

Je combineert hier twee factoren die de lage write performance veroorzaken: RAID5 en SSDs. Bij het schrijven in RAID5 zijn alle aangesloten disks bezig en een SSD is nou eenmaal niet zo rap met schrijven als dit niet sequentieel is.

[Verwijderd]

gertvdijk schreef op vrijdag 23 januari 2009 @ 13:46:
[...]

Je combineert hier twee factoren die de lage write performance veroorzaken: RAID5 en SSDs. Bij het schrijven in RAID5 zijn alle aangesloten disks bezig en een SSD is nou eenmaal niet zo rap met schrijven als dit niet sequentieel is.

Das waar en de bedoeling is dus ook om het omhoog te krijgen. In een andere test schaal ik disken op, van 4 t/m 12 en dan 2x5 en 2x6. Je ziet dan ook de performance telkens toenemen. Vooral bij de 2x5 komt er een grote jump. Echter, die gaten in easyco snap ik niet. De performance is dan opeens bij een bepaalde block size compleet weg. Dat lijkt me toch iets anders dan de algemene wijsheid dat SSD trage writes en RAID 5 trage(re) writes.

In weer een andere test heb ik RAID levels (op 1 disk) vergeleken, en RAID 10, RAID 5 en RAID 6 schaalde regelmatig omlaag. Alleen tussen RAID 0 en RAID 10 zat een grote jump.