Experimentele karakterisatie van doorvoersnelheid en redundantie van relatief goedkope en kleinschalige diskspace

Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Experimentele karakterisatie van doorvoersnelheid en redundantie van relatief goedkope en kleinschalige diskspace door Emmanuel VANNESTE

Promotor: Prof. Dr. Ir. P. DEMEESTER Scriptiebegeleiders: Dr. Ir. B. VERMEULEN, Lic. S. DE SMET, Ir. S. EECKHAUT

Scriptie ingediend tot het behalen van de academische graad van licentiaat in de informatica

Academiejaar 2005–2006

Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Experimentele karakterisatie van doorvoersnelheid en redundantie van relatief goedkope en kleinschalige diskspace door Emmanuel VANNESTE

Promotor: Prof. Dr. Ir. P. DEMEESTER Scriptiebegeleiders: Dr. Ir. B. VERMEULEN, Lic. S. DE SMET, Ir. S. EECKHAUT

Scriptie ingediend tot het behalen van de academische graad van licentiaat in de informatica

Academiejaar 2005–2006

Dankwoord Eerst en vooral zou ik mijn begeleiders Brecht, Stijn D.S. en Stijn E. uitvoerig willen bedanken voor de vele hulp die ze mij tijdens het verloop van de thesis geboden hebben. Ik had me geen betere thesisbegeleiders kunnen wensen!

Daarnaast wil ik zeker ook mijn promotor Prof. Dr. Ir. P. Demeester uitgebreid bedanken om deze praktijkgerichte thesis mogelijk te maken; het onderwerp waar ik oorspronkelijk interesse in vertoonde was reeds bezet, doch vormde het geen enkel probleem om een soortgelijk onderwerp te definiëren. Bedankt daarvoor!

Ten slotte zou ik ook mijn ouders willen bedanken voor het nalezen van dit manuscript, en — veel belangrijker uiteraard — voor de mogelijkheid die ze mij geboden hebben om de opleiding informatica te volgen.

Emmanuel Vanneste, juni 2006

Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Emmanuel Vanneste, juni 2006

Experimentele karakterisatie van doorvoersnelheid en redundantie van relatief goedkope en kleinschalige diskspace door Emmanuel VANNESTE Scriptie ingediend tot het behalen van de academische graad van licentiaat in de informatica Academiejaar 2005–2006 Promotor: Prof. Dr. Ir. P. DEMEESTER Scriptiebegeleiders: Dr. Ir. B. VERMEULEN, Lic. S. DE SMET, Ir. S. EECKHAUT Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Samenvatting In onze hedendaagse samenleving worden er elke dag meer en meer data opgeslagen. Uiteraard wil men die data op een snelle en veilige manier opslaan, en eenmaal ze opgeslagen zijn wil men ze ook aan een zo hoog mogelijke snelheid aan de gebruikers kunnen aanbieden. In deze thesis gaan we — m.b.v. verschillende benchmarks — dan ook op zoek naar de optimale storage voor verschillende applicaties.

Trefwoorden diskspace, RAID, redundantie, storage

Experimental characterisation of throughput and redundancy of relatively small and inexpensive diskspace Emmanuel Vanneste Supervisor(s): Piet Demeester, Brecht Vermeulen, Stijn De Smet, Stijn Eeckhaut Abstract—The amount of data which needs to be stored in modern (digitalized) society, is getting larger day by day. Ideally, the storage of this data should occur in a safe and quick way. Furthermore, once the data is stored, users want to be able to access it at the highest speed possible. In this article, we try to determine the optimal storage for different applications, by using various benchmarks. Keywords—diskspace, RAID, redundancy, storage

I. I NTRODUCTION Whether data is stored on an FTP-server or in a database, typically always the same goal is kept in mind: The data needs to be stored in a safe and quick way, and afterwards clients have to be able to access that data at the highest bandwidth possible. In this article, we will examine how an optimal diskspacethroughput for different applications can be achieved, without neglecting the redundancy of the data. To accomplish this, a bottom-up approach is used. We start on the disk-level, then move on to the filesystem-level, then consider the RAID-level (here the redundancy comes up), and eventually arrive on the application-level. II. D ISK - LEVEL At first the performance of a single disk at the lowest level was being examined. To accomplish this, we used a wide range of disktools, of which Disktesttool[2] eventually proved to be the most versatile one (since it was able to measure both the sequential and random read- and write-throughput of the disks). Different kind of disks were being examined: A rather expensive SCSI-disk (Seagate), a somewhat less expensive SATA-disk (Raptor), and two pretty cheap SATA-disks (Hitachi and Maxtor). The expensive disks obviously had better specifications (RPM and seek-time) than the cheaper ones. By means of our tests, we wanted to get to know, if the disk with the better specifications in every situation (sequential/random read/write) also corresponded with a better throughput. The benchmarks told us that for the reads (both sequential and random) this always proved to be right, yet for the writes it wasn’t necessarily true. Since the SATA-disks by default were configured with a write-back cache, they could approach the write throughput of the SCSI-disk (which didn’t use write-back caching); without write-back caching however the SATA-disks performed a lot worse than the SCSI-disks. When using write-back-caching, there’s a certain risk to dataloss though. Therefore we could conclude that for temporary E. Vanneste is with the Information Technology (INTEC) Department, Ghent University (UGent), Gent, Belgium. E-mail: [email protected]

storage — where dataloss doesn’t give too many problems — cheap SATA-disks are the way to go, while for storage which doesn’t tolerate any dataloss (like databases and so on) SCSIdisks are the better choice. III. F ILESYSTEM - LEVEL After having examined the performance of one disk on the lowest level, we moved on to the filesystem-level. Both the Linux-filesystems xfs, reiserfs, ext3, ext2 and jfs and the Windows-filesystem ntfs were being examined, by using the filesystem-benchmarktool IOzone[3]. The tests showed us that the performance of the different Linux-filesystems was quite similar, but that xfs overall performed slightly better than the others. The results obtained for ntfs were very different, but since we couldn’t find out if Iozone performed exactly the same way in Linux as in Windows, those results had to be considered with the necessary caution. IV. RAID- LEVEL Having considered the performance of one disk on both the disk-level and the filesystem-level, we could examine how a set of disks (in a RAID-array) performed. Both hardware-RAID (SCSI and SATA) and software-RAID (SATA) were being examined, in order to be able to determine the best performing RAID-type, for each specific RAID-level. Both RAID0, RAID1, RAID5, RAID6 and RAID10 were examined by using Disktesttool, the disktool which has already been discussed on the disk-level. Apart from the performance of the RAID-arrays in normal mode, the performance in degraded and rebuilding mode was also being measured. Those benchmarks provided us with a lot of interesting insights: For RAID0, the expectations were met for all RAID-types (SCSI-hardware (SCSI), SATA-hardware (SATA) and SATAsoftware (SOFT)). The performance of SOFT was similar to the one of SATA, and since SOFT was a lot cheaper than SATA, SOFT appeared to be the obvious choice for RAID0. For RAID1, the random read performance of SOFT was better than the one of SATA, while for the other types of access the performance was equal. Adding that to the lower price of SOFT, the choice for SOFT seemed logical yet again. The RAID5-performance of SOFT was pretty good as well, yet with write-back-caching enabled, the hardware-RAID proved to be better. Without write-back caching (so in writethrough-mode) the hardware-RAID performed rather poor, but nevertheless it has to be highlighted that write-back caching im-

plies a risk to dataloss. One can eliminate that risk however, by adding a battery-backup-unit to the hardware-RAID-controller. Hardware-RAID5 also has the advantage that it doesn’t use any CPU-power, which might come in handy in a system with high CPU-usage. At last we also could notice that in degraded mode, SATA performed a lot better than SCSI and SOFT. For RAID6, the performance of SOFT was rather poor, while the one of SATA was really good. SCSI couldn’t be examined for this RAID-level, since the SCSI-controller didn’t support the relatively new RAID6-level. The RAID10-performance of SOFT was equal to the one of SATA for the reading, yet for the writing SATA proved to be a lot better. Once again SCSI couldn’t be examined, since the number of available SCSI-disks wasn’t sufficient for this RAIDlevel.

Fig. 1. FTP-bandwidth (MB/s), for storage-intensive FTP-behaviour

V. A PPLICATION - LEVEL In previous sections, we have examined the throughput of the storage by means of different benchmarks. Now in this section, we want to verify if those benchmarked throughputs correspond with the throughputs of some realistic applications. Both FTP and MySQL are being examined. A. FTP FTP-clients typically want to exchange relatively big files with the FTP-server, which makes a high FTP-bandwidth extremely desirable. Since the access pattern to the FTP-server can be quite different, we considered two extremes, and tried to establish a high FTP-bandwidth for both of them. At first we considered the extreme in which a very high number of FTP-clients all requested the same file. In this case the FTP-server only had to access his disk-storage once, because after that, he could read the file out of his buffer-cache, again and again. These tests proved that despite the very high number of simultaneous users, the FTP-server continuously could offer the maximum FTP-bandwidth. The more simultaneous FTP-clients, the more FTP-server-memory was used however, so if an FTPserver wants to be able to deal with a lot of simultaneous clients, a lot of memory appears to be essential. Secondly the extreme in which a relatively small number of FTP-clients all requested different files, was being considered. In this case, the FTP-server couldn’t read anything out of his buffer-cache, and the disk-access was maximal. That way we could obtain a very good overview of the influence of the used storage on the achieved FTP-bandwidth. Figure 1 displays the results of these tests. For this storage-intensive FTP-access-pattern, we distinguished two types, BEST and WORST. In the BEST case, one FTP-user read ten different files from the beginning of the storage, while in the worst case, two different users were reading simultaneously from the beginning and the end of the FTP-server-storage. These tests gave us the interesting insight that the benchmarked throughputs (obtained in the previous sections) actually corresponded with the diskspace-throughputs of a realistic application. Next to that, we also could notice that for the BEST FTP-access-pattern, SCSI-RAID performed slightly better than

SATA-RAID. However we have to highlight that the BEST case was mainly examined to get to know the maximum possible FTP-bandwidth for the storage, since in real life, that BEST FTP-access-pattern doesn’t occur too much. In real life, the WORST FTP-pattern will be far more common, since it will typically be multiple (and not one) FTP-clients who request different files. Surprisingly, for the WORST access-pattern, SATARAID could realise a better FTP-bandwidth than (the more expensive!) SCSI-RAID. Therefore we could conclude that SATARAID appears to be the perfect FTP-server-storage. B. MySQL Contrary to FTP, MySQL typically executes very short random disk accesses. In previous sections, the benchmarks had shown that the random throughput — especially the random read throughput — of SCSI-RAID, was a lot better than the one of SATA-RAID, thanks to the very good access time of its SCSI-disks. Now, by means of a realistic MySQL-application, we wanted to find out if those benchmark-insights corresponded with reality. To establish a realistic MySQL-load, we used an e-commerce test-application from Dell[1], named DVD Store Version 2. Both SCSI-RAID5 and SOFT-RAID5 were being examined as the storage of the MySQL-server. And yes, the test-application indeed confirmed our previously obtained benchmark-results. VI. C ONCLUSIONS We have realised an optimal bandwidth for both FTP and MySQL, while taking care of the redundancy of the data, so we can conclude that our goal has been achieved. R EFERENCES [1] DVD Store Version 2, http://linux.dell.com/dvdstore/ [2] Disktesttool, developed by Stijn De Smet, not publicly available [3] IOzone, http://www.iozone.org/

INHOUDSOPGAVE

i

Inhoudsopgave 1 Inleiding

1

1.1

Doel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Aanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2 Schijf-niveau

3

2.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

Onderzochte schijven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.3

Onderzochte disktools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.4

Disktesttool, de beste disktool . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.4.1

Sequentiële doorvoersnelheid . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.4.2

Random doorvoersnelheid . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.4.3

Caching uitschakelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

Resultaten Disktesttool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.5.1

Sequentieel lezen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.5.2

Random lezen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.5.3

Sequentieel schrijven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.5.4

Random schrijven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.5

2.6

3 Bestandssysteem-niveau

20

3.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.2

IOZone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.3

Resultaten IOzone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.3.1

Sequentieel lezen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.3.2

Sequentieel schrijven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

INHOUDSOPGAVE

3.4

ii

3.3.3

Random lezen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.3.4

Random schrijven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.3.5

CPU-verbruik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4 RAID-niveau

30

4.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.2

Beschouwde RAID-niveaus

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.2.1

RAID1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.2.2

RAID0

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

4.2.3

RAID5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.2.4

RAID6

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.2.5

RAID10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.3

Beschouwde RAID-configuraties . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.4

Omschrijving tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

4.4.1

Normaal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

4.4.2

Degraded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

4.4.3

Rebuilding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

4.5.1

RAID1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

4.5.2

RAID0

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

4.5.3

RAID5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

4.5.4

RAID6

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4.5.5

RAID10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

4.5.6

CPU-verbruik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

4.5

4.6

5 Applicatie-niveau 5.1

61

FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

5.1.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

5.1.2

Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

5.1.3

Veel clients die allemaal hetzelfde bestand downloaden . . . . . . . . . . .

65

5.1.4

Weinig clients die allemaal verschillende bestanden downloaden . . . . . .

67

INHOUDSOPGAVE

5.1.5 5.2

iii

Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

5.2.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

5.2.2

Beschrijving DS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

5.2.3

Initialisatie DS2-tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

5.2.4

Omschrijving DS2-tests . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

5.2.5

Resultaten DS2-tests en conclusies . . . . . . . . . . . . . . . . . . . . . .

80

6 Conclusie en mogelijkheden tot verder onderzoek

82

6.1

Besluiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

6.2

Verder onderzoek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

A Loadgen

85

B Vsftpd: vsftdp.conf

87

C MySQL: my.conf

92

INLEIDING

1

Hoofdstuk 1

Inleiding

1.1

Doel

De hoeveelheid data die de dag van vandaag moet opgeslagen worden, neemt alsmaar toe. Of het nu de storage van een FTP-server of die van een databank betreft, typisch wordt steeds hetzelfde doel voor ogen gehouden: Men wil de data op een snelle en efficiënte manier bewaren, en daarnaast bij voorkeur ook enige redundantie voorzien, zodat de data in geval van problemen zeker niet verloren gaan. Eenmaal de data opgeslagen zijn, wil men ze uiteraard ook aan een zo hoog mogelijke snelheid aan de gebruiker kunnen aanbieden. In deze thesis wordt dan ook onderzocht hoe we voor verschillende applicaties een optimale diskspace-doorvoersnelheid kunnen realiseren, zonder daarbij de redundantie uit het oog te verliezen. We spitsen ons toe op relatief kleinschalige diskspace, die zich binnen één server situeert. De prijs van de storage is ook een belangrijke factor, aangezien we op zoek gaan naar de diskspace die een zo hoog mogelijke doorvoersnelheid aan een zo laag mogelijke prijs realiseert. Het doel van de thesis kan dus kort samengevat worden als: Voor verschillende applicaties, de storage met de beste prijs/kwaliteit-verhouding bepalen.

1.2 Aanpak

1.2

2

Aanpak

Om die optimale storage te kunnen bepalen, werd een bottom-up aanpak gehanteerd. We startten helemaal onderaan bij het schijf-niveau (hoofdstuk 2), om dan via het bestandssysteemniveau (hoofdstuk 3) en het RAID-niveau (hoofdstuk 4) uiteindelijk bij het applicatie-niveau (hoofdstuk 5) te belanden. In hoofdstuk 6 worden de resultaten ten slotte nog eens kort samengevat, en bespreken we eventuele mogelijkheden tot verder onderzoek.

SCHIJF-NIVEAU

3

Hoofdstuk 2

Schijf-niveau

2.1

Inleiding

Zoals in het inleidende hoofdstuk reeds werd aangehaald, werd het bottom-up storage-onderzoek gestart met het opmeten van de doorvoersnelheid van één schijf op het laagste niveau; het schijfniveau. Om de schijf-niveau-performantie na te gaan werd een brede waaier aan disktools beschouwd. Het hoofddoel van al die testen was natuurlijk om een goed idee te krijgen van de schijfperformantie, maar anderzijds wilden we ook een overzicht krijgen van de specifieke schijfkarakteristieken die elke disktool kon weergeven, om er vervolgens de beste uit te kunnen selecteren. Alle schijf-niveau-tests werden uitgevoerd op dezelfde machine (Athena80), waarvan de specificaties in tabel 2.1 terug te vinden zijn.

2.2

Onderzochte schijven

Er werden vier verschillende schijven onderzocht, waarvan de specificaties weergegeven worden in tabel 2.2. Qua SCSI werd een Seagate-schijf beschouwd, waarvan de specificaties uiterst

2.3 Onderzochte disktools

4

CPU

AMD Athlon(tm) 64 Processor 3500+ (2.2 GHz)

L1 Cache

64 KB instructie- en 64 KB datacache

L2 Cache

512 KB

Moederbord

Asus A8N-SLI Deluxe

Geheugen

2 GB

OS-disk

Maxtor 6B200M0 (200 GB)

onboard SATA-contr.

Nvidia SiliconImage 3114

OS

Ubuntu breezy 5.10 64-bit met 2.6.13.4-kernel Microsoft Windows XP Professional Version 2002 SP2 Tabel 2.1: Specificaties Athena80

goed zijn maar de prijs ook navenant is. Daarnaast werden drie verschillende SATA-schijven beschouwd, waarbij de Western Digital (WD) de beste, de Hitachi de middelste en de Maxtor de slechtste specificaties heeft. Wanneer we de kostprijs per GB schijfruimte van de verschillende

/GB — beschouwen, dan zien we dat naargelang de schijf over betere specificaties beschikt, die /GB ook gevoelig toeneemt (op schijven — in tabel 2.2 terug te vinden onder de noemer

uitzondering van de Hitachi-schijf, die niettegenstaande hij over iets betere specificaties dan de Maxtor-schijf beschikt toch goedkoper is). Uiteraard staat het nog niet vast dat de duurste schijf in alle gevallen ook de beste doorvoersnelheid zal kunnen realiseren, en dat is dan ook exact wat in dit hoofdstuk onderzocht wordt: Levert de schijf met de beste specificaties (laagste zoektijd, hoogste toerental) in alle gevallen ook wel degelijk de beste doorvoersnelheid?

2.3

Onderzochte disktools

Zoals gezegd werd er een groot gamma disktools beschouwd. Onder Windows kwamen Diskspeed32 (3.0.0.5), HDTune (2.51) en HDTach (3.0.1.0) aan bod; onder Linux werden Zcav (1.03), dd (5.2.1) en Diskttestool (1.0) beschouwd. De belangrijkste schijfkarakteristieken die deze disktools kunnen opmeten worden weergegeven


5

Naam

Code

Int.a

Z.b

RPMc

B.d

P.e

f

GBg

/GBh

Seagate

ST373453LW

SCSI

3.6

15000

8

4

626

73

8.58

WD

WD360GD

SATA

4.5

10000

8

1

123

36

3.42

Hitachi

HDS722516VLSA80

8.5

7200

8

2

94

160

0.59

Maxtor

6Y080M0

9.3

7200

8

1

57

80

0.71

Tabel 2.2: Overzicht van de schijven gebruikt tijdens de schijf-niveau-tests a

Interface Gemiddelde leeszoektijd (in ms) c Rounds Per Minute; het toerental d Buffergrootte (in MB) e Aantal platters f Prijzen (incl. BTW) van www.mpl.be of van www.vdhsoft.be indien daar niet beschikbaar g Schijfcapaciteit (in GB) h Kostprijs per GB schijfruimte b

in tabel 2.3. We onderscheiden enerzijds de toegangstijd en anderzijds de doorvoersnelheid van de schijf. De toegangstijd is de tijd tussen een aanvraag naar de schijf (dit kan zowel een leesals schrijfoperatie zijn) en het begin van de effectieve datatransfer. De doorvoersnelheid is de snelheid waarmee er data naar/van de schijf kunnen getransfereerd worden. Uiteraard zal deze snelheid verschillend zijn voor verschillende toegangspatronen tot de schijf (sequentieel vs. random lezen/schrijven), zodoende beschouwen we dan ook voor welke specifieke toegangspatronen de bewuste disktool de doorvoersnelheid allemaal kan opmeten. Terloops merken we nog op dat sequentiële schijftoegang optreedt bij bv. videostreaming, waartegenover korte random schijftoegang zich typisch bij een databank voordoet. Disktool

OS

Toegangstijd

Doorvoersnelheid Sequentieel Lezen

Diskspeed32

Y

Y

HDTune

Y

Y

HDTach

Y

Y

Zcav

Windows

Linux

Schrijven

Random Lezen

Schrijven

Y

Y

Y

dd

Y

Y

Disktesttool

Y

Y

Tabel 2.3: Overzicht belangrijkste schijfkarakteristieken die de disktools kunnen opmeten


6

Uit tabel 2.3 blijkt dat Disktesttool de meest veelzijdige disktool is, hij kan nl. zowel de sequentiële als random lees/schrijf-doorvoersnelheid opmeten. Deze disktool laat niet toe om de (gemiddelde) toegangstijd van de schijf te meten, maar dit is geen tekort. De toegangstijd kan namelijk makkelijk berekend worden als de som van de zoektijd en de omwentelingsvertragingstijd van de schijf. De zoektijd is de tijd die nodig is om de schijfkop naar het juiste spoor te verplaatsen, en de omwentelingsvertragingstijd deze die vereist is om — eenmaal de schijfkop zich op het juiste spoor bevindt — de benodigde sector dan nog tot onder de schijfkop te laten wentelen. De waarde van de zoektijd is steeds terug te vinden in de documentatie van de schijf, en de omwentelingsvertragingstijd kan gemakkelijk afgeleid worden uit het schijftoerental (RPM) dat eveneens in die documentatie aanwezig is. Zoals we in tabel 2.2 kunnen zien is de zoektijd voor de Seagate SCSI-schijf 3.6 ms. Daarnaast omwentelt die schijf aan 15000 R(ounds) P(er) M(inute), één omwenteling duurt dus 4 ms. En aangezien er gemiddeld een halve omwenteling moet gemaakt worden vooraleer de benodigde sector onder de schijfkop terechtgekomen is, kunnen we dus 2 ms in rekening brengen. Wanneer we de zoektijd en de omwentelingsvertragingstijd van de SCSI-schijf nu sommeren, dan komen we uit op 5.6 ms. Op figuur 2.1 zien we nu dat die berekende waarde exact overeenkomt met de waarden die de disktools — die in tegenstelling tot Disktesttool wél de toegangstijd konden nagaan — opgemeten hadden. Bij de Hitachi SATA-schijf is het toerental 7200 RPM, een halve omwenteling duurt dus 4.15 ms. In combinatie met een zoektijd van 8.5 ms levert dit een gemiddelde toegangstijd van 12.65 ms. Opnieuw zien we op figuur 2.1 dat deze waarde mooi overeenkomt met de waarden die door de disktools Diskspeed32, HDTune en HDTach opgemeten werden. We kunnen dus besluiten dat het niet-opmeten van de toegangstijd geen tekort aan Disktesttool is, vermits we die waarde toch vrij eenvoudig zelf accuraat kunnen berekenen. Daarenboven wordt de toegangstijd doorgaans opgemeten om te kunnen bepalen hoe goed de schijf presteert bij random, heel korte schijftoegang. Bij een dergelijke schijftoegang zal de toegangstijd van de schijf immers primordiaal zijn, vermits de schijfkop zich telkens naar een nieuwe random locatie op de schijf moet verplaatsen, daar vervolgens een kleine hoeveelheid data leest/schrijft, zich naar de volgende random locatie verplaatst, daar opnieuw een heel kleine hoeveelheid data

2.4 Disktesttool, de beste disktool

7

Figuur 2.1: Toegangstijd (ms) van bepaalde schijven, opgemeten met verschillende disktools

leest, etc. Hierbij is de kost van de datatransfer dus verwaarloosbaar, en zal de toegangstijd de vertragende factor zijn. De toegangstijd staat dus in nauw verband met de random doorvoersnelheid van de schijf, en aangezien Disktesttool ook deze random doorvoersnelheid kon opmeten kunnen we besluiten dat het de meest veelzijdige disktool is.

2.4

Disktesttool, de beste disktool

Disktesttool is een command-line Linux-disktool die ontworpen werd door mijn thesisbegeleider Stijn De Smet. Zoals in tabel 2.3 reeds aangegeven werd kan Disktesttool zowel de sequentiële als random lees- en schrijfsnelheid van de schijf opmeten, hiertoe worden sequentieel of random blokken van een bepaalde transfer-blokgrootte naar of van de schijf getransfereerd. Deze transferblokgrootte — de hoeveelheid bytes die in één keer met de schijf uitgewisseld wordt — werd voor de schijf-tests uit dit hoofdstuk telkens op 128 KB ingesteld, aangezien dit ook de default blokgrootte was waarmee de Linux-kernel met zijn blockdevices communiceerde (na te gaan met het commando blockdev --getra /dev/sdb).


Figuur 2.2: Opbouw van een schijf

8


2.4.1

9

Sequenti¨ ele doorvoersnelheid

Zoals we in figuur 2.21 kunnen zien, bevinden zich in het schijfbegin (op de buitenste cylinder) het grootst aantal sectoren per spoor en op het schijfeinde (op de binnenste cylinder) het kleinste aantal. Aangezien het aantal Rounds Per Minute voor de hele schijf constant is, betekent dit dus dat er in het begin van de schijf het meest sectoren kunnen aangedaan worden in één schijfomwenteling en op het einde van de schijf het minst. Zodoende zal de sequentiële doorvoersnelheid in het begin van de schijf maximaal, en op het einde van de schijf minimaal zijn. Disktesttool mat zowel die maximale als minimale doorvoersnelheid, en las of schreef hiervoor dus sequentieel een hoeveelheid data (512 MB) van/naar respectievelijk het begin of einde van de schijf.

2.4.2

Random doorvoersnelheid

Bij de random lees- en schrijfsnelheden onderscheiden we opnieuw twee doorvoersnelheden, enerzijds de minimale en anderzijds de gemiddelde. De minimale doorvoersnelheid treedt op wanneer er afwisselend blokken gelezen/geschreven worden van/naar het begin en einde van de schijf, omdat de schijfkop zich dan telkens over een maximale afstand — tussen het begin en einde van de schijf — moet verplaatsen. Deze maximale schijfkopverplaatsing is een uiterst dure operatie, waardoor de hoeveelheid data die in een bepaald interval naar/van de schijf getransfereerd kan worden minimaal is, en de resulterende doorvoersnelheid derhalve ook minimaal is. Om deze doorvoersnelheid op te meten switchte Disktesttool dus constant tussen het begin en einde van de schijf om daar telkens een blok van 128 KB te lezen of te schrijven. Om de gemiddelde random doorvoersnelheid op te meten werd niet langer tussen het begin en einde van de schijf afgewisseld, maar werd nu gewoon volledig random — schijflocatie 20 maakte dus evenveel kans om aangedaan te worden als locaties 1025, 9998, etc. — een bepaald blok van/naar de schijf gelezen/geschreven. Bij de random tests werd net zoals bij de sequentiële in totaal ook telkens 512 MB getransfereerd. 1

Afbeelding van op http://doc.nl.linux.org/GUIDE/sag-nl/hd-schematic.png


2.4.3

10

Caching uitschakelen

Bij het opmeten van de schrijfsnelheden m.b.v. Disktesttool was het belangrijk dat de cache van de controller waarop de beschouwde schijf werd aangesloten als write-through geconfigureerd was. Bij een write-through controller-cache worden de data simultaan naar de controller-cache en de schijf zelf weggeschreven. Bij een write-back controller-cache daarentegen worden de data weliswaar ogenblikkelijk naar de controller-cache geschreven, maar pas naar de aangesloten schijf wanneer de controller dit nuttig acht, wat dus impliceert dat een write-back cache typisch een betere performantie levert dan een write-through-cache aangezien hij de schrijfacties efficiënter kan organiseren. Een write-back cache is echter wel minder veilig dan de write-through-variant, aangezien in het geval dat de controller zonder stroom komt te zitten, alle data die zich in die cache bevonden en nog niet naar de schijf weggeschreven waren, verloren gaan. Zoals reeds vermeld, werd bij het slechtste random toegangspatroon telkens afwisselend één blok van helemaal vooraan en helemaal achteraan de schijf gelezen. Bij een write-through cache worden de data ogenblikkelijk ook naar de schijf weggeschreven, wat dus impliceert dat de schijfkop effectief constant tussen het begin en het einde van de schijf moet switchen. In het geval van een write-back cache daarentegen kan de controller beslissen om te wachten om tot het schrijven naar de schijf over te gaan totdat er zich bv. tien blokken van helemaal vooraan en tien van helemaal achteraan de schijf in de write-back-cache bevinden. Hierbij kunnen de eerste tien blokken dan sequentieel naar de schijf weggeschreven worden, en is er vervolgens slechts één maximale schijfkop-verplaatsing nodig om het einde van de schijf te bereiken en de laatste tien blokken daar dan ook sequentieel weg te schrijven. Concreet zal er hier bij een write-back-cache slechts één maximale — van het begin naar het einde van de schijf — schijfkopverplaatsing nodig zijn, waartegenover er bij de write-through-cache 19 nodig waren. Zoals reeds gezegd is de maximale schijfkopverplaatsing een erg dure operatie, het verschil in (minimale) random doorvoersnelheid wanneer de schijf enerzijds op een controller met write-back-cache of anderzijds op één met write-through-cache aangesloten is, zal dan ook gigantisch zijn. Niettegenstaande een write-back controller-cache hogere doorvoersnelheden kan realiseren werd toch voor een write-through controller-cache geopteerd, zodat we een goed overzicht kregen van de werkelijke doorvoersnelheden van de schijven, zonder optimalisaties in de controller.


11

Zoals we in tabel 2.1 reeds konden zien waren er op het moederbord van Athena80 reeds twee SATA-controllers aanwezig (van Nvidia en SiliconImage). De cache van deze onboard-controllers kon echter niet op write-through ingesteld worden, zodoende moest voor een externe SATAcontroller — waarvan de cache wel als write-through kon geconfigureerd worden — geopteerd worden. Meer concreet werd een Areca ARC-1220 controller gebruikt, een geavanceerde SATARAID controller die ook toelaat om de erop aangesloten schijven als passthrough-disks te definiëren. Een dergelijke schijf maakt dan geen deel uit van een RAID-array, maar wordt door het besturingssysteem als een gewone schijf — alsof deze rechtstreeks op het moederbord aangesloten is — aanzien. Uiteraard werd eerst nagegaan of een schijf in passthrough-mode aangesloten op de Arecacontroller ook effectief dezelfde leesperformantie bood als wanneer de schijf op een onboardSATA-controller (hetzij de Nvidia of de SiliconImage) aangesloten werd. In figuur 2.3 wordt de maximale sequentiële leessnelheid voor de Hitachi-schijf aangesloten op de drie verschillende SATA-controllers weergegeven. Uit de waarnemingen van twee onafhankelijke testtools (HDtune onder Windows en Zcav onder Linux) blijkt inderdaad dat er geen performantieverschil optreedt, wanneer die schijf op enerzijds de Areca-controller of anderzijds een onboard-controller aangesloten wordt. Derhalve kon de prestatie van de SATA-schijven dan ook nauwkeurig opgemeten worden wanneer deze schijven aangesloten werden op de Areca-controller met write-throughcache.

Figuur 2.3: Maximale sequentiële doorvoersnelheid (MB/s) van de Hitachi-schijf aangesloten op verschillende controllers, opgemeten met onafhankelijke disktools

2.5 Resultaten Disktesttool

12

Naast SATA-schijven werd zoals gezegd ook één SCSI-schijf, nl. de Seagate, onderzocht. Op Athena80’s moederbord was er geen SCSI-slot aanwezig, zodoende moest voor de SCSI-tests sowieso voor een externe SCSI-controller geopteerd worden. Meer concreet werd een LSI Logic MegaRAID SCSI 320-2E gebruikt. Net zoals de Areca is ook deze controller eigenlijk een geavanceerde RAID-controller, maar ook hij staat accurate single-disk-tests toe. De SCSI-controller ondersteunt weliswaar geen pass-through disks, doch met een RAID0-array met een stripe-size van 128 KB bestaande uit één schijf, kon een soortgelijke configuratie gerealiseerd worden.

2.5

2.5.1

Resultaten Disktesttool

Sequentieel lezen

Figuur 2.4: Sequentiële leessnelheid (MB/s) van de beschouwde schijven

Uit de Max(imale) doorvoersnelheden op figuur 2.4 blijkt dat de schijven met de beste specificaties ook de beste sequentiële doorvoersnelheden kunnen realiseren. Ook voor de minimale doorvoersnelheden wordt die rangorde bevestigd. Daarnaast merken we nog op dat het verschil tussen de maximale en minimale doorvoersnelheid


13

groter is bij de Maxtor en Hitachi dan bij de WD en Seagate-schijf. Dit komt omdat de platters — een schijf bestaat uit één of meerdere platen die zich boven elkaar bevinden — van de Hitachi en Maxtor-schijven groter zijn dan deze van de WD en Seagate. Zodoende is op die schijven het aantal sectoren op de binnenste cylinder veel kleiner dan het aantal op de buitenste, wat er dus voor zal zorgen dat de minimale doorvoersnelheid (op de binnenste cylinder) bijgevolg veel kleiner is dan de maximale.

2.5.2

Random lezen

Figuur 2.5: Random leessnelheid (MB/s)

Uit figuur 2.5 blijkt dat — net zoals bij het sequentiële lezen — ook hier de schijf met de beste specificaties de beste doorvoersnelheid realiseert. Het performantieverschil tussen de verschillende schijven is hier nu, zowel voor de minimale als de gemiddelde random read leessnelheid, wel veel meer uitgesproken dan dat bij het sequentiële lezen het geval was. Zoals gezegd wisselt Disktesttool bij de random-simulaties telkens een heel kleine hoeveelheid data (128KB) met de schijf uit, om vervolgens naar een andere locatie op de schijf te springen, daar opnieuw 128 KB te transfereren, etc. Aangezien de schijfkop zich dus telkens over een vrij grote afstand — bij de minimale doorvoersnelheid-simulatie zelfs telkens over de volledige schijf — moet verplaatsen, zal de toegangstijd van de schijven hier dus primordiaal bij zijn. Zoals in figuur 2.6 te zien is,


14

zijn de toegangstijden van de beschouwde schijven serieus verschillend, wat het grote verschil in de random read leessnelheden dan ook verklaart.

Figuur 2.6: Toegangstijd (ms) van de beschouwde schijven; hoe lager hoe beter!

2.5.3

Sequentieel schrijven

Figuur 2.7:

Sequentiële schrijfsnelheid (MB/s); SATA-schijfcache = write-back en SCSI-

schijfcache = write-through

Uit figuur 2.7 blijkt verrassend dat de sequentiële schrijfsnelheden van de SATA-schijven deze van de SCSI-schijf bijna evenaren (of zelfs beter zijn, in geval van de WD-schijf). Bij de Maxtor en


15

WD-schijf zijn de sequentiële schrijfsnelheden dan ook sneller dan hun sequentiële leessnelheden, iets wat door de mechanische structuur van een schijf normaalgesproken onmogelijk is. Nader onderzoek leerde echter dat die hoge schrijfsnelheden bij de SATA-schijven veroorzaakt worden door caching, meer concreet stond de cache van die schijven default reeds op write-back ingesteld. Voorheen werd reeds vermeld dat bij alle testen de controller-cache op write-through ingesteld werd, maar daarnaast beschikken de schijven zelf ook nog eens over een cache. Bij SCSI-schijven staat die cache doorgaans default op write-through ingesteld, doch bij SATA-schijven wordt ze default op write-back ingesteld om zo haar mindere performantie (door slechtere zoektijd en lagere RPM) t.o.v. SCSI enigszins te kunnen goedmaken. Zodoende werd de cache van de SATA-schijven dan ook eens expliciet op write-through ingesteld2 , en zoals we in figuur 2.10 kunnen zien is de sequentiële schrijfsnelheid dan inderdaad enorm veel lager dan wanneer de schijf-cache op zijn default (write-back) ingesteld staat. Met die write-through cache is de sequentiële schrijfsnelheid dan ook een pak slechter dan deze van de SCSI-schijf (waarvan de cache default reeds op write-through ingesteld stond), en dan ook slechter dan de sequentiële leessnelheid van de respectievelijke SATA-schijven. Wanneer we willen dat de sequentiële schrijfsnelheid van de SATA-schijven optimaal is, dan moeten we de schijfcache dus zeker op zijn default (write-back) laten staan. Zoals in de bespreking van de controller-cache reeds opgemerkt werd, is een write-back cache ondanks de betere performantie wel veel minder veilig dan een write-through-cache. Indien er zich bij een stroomonderbreking data in de schijfcache bevinden die nog niet effectief naar de schijf weggeschreven werden, dan gaan die data verloren, wat dan bijvoorbeeld in een corrupt bestandssysteem kan resulteren. Uiteraard kunnen de SATA-schijven — indien mogelijk — ook van een redundante voeding voorzien worden, maar aangezien ook die voeding zonder stroom kan komen te zitten blijft het risico op dataverlies reëel. Ten slotte merken we nog op dat er niet kon nagegaan worden hoe de performantie van de SCSIschijf met een write-back cache was, aangezien het niet duidelijk was hoe de write-through cache van de Seagate-SCSI-schijf naar een write-back kon veranderd worden. Doch op zich vormt dit geen probleem, aangezien er verwacht kan worden dat wanneer men voor duurdere SCSI-schijven 2

In het Areca-configuratiepanel waarin we de SATA-schijf reeds als pass-through-disk gedefinieerd hadden,

konden we de write-back schijfcache expliciet disablen, in het System Configurations menu


16

Figuur 2.8: Sequentiële schrijfsnelheid (MB/s); SATA-schijfcache = write-through en SCSIschijfcache = write-through

opteert, men geen dataverlies tolereert, en de default write-through-cache van de SCSI-schijven dan ook ideaal is.

2.5.4

Random schrijven

Net zoals bij het sequentiële schrijven kunnen we in figuur 2.9 opnieuw vaststellen hoe het feit dat de cache van de SATA-schijven default op write-back ingesteld staat, er opnieuw voor zorgt dat de random schrijfsnelheid van de SATA-schijven in de buurt komt van die van de SCSI-schijf (en daarnaast ook weer groter is dan de random leessnelheid van de respectievelijke SATA-schijven). Vooral bij de minimale random schrijfsnelheden is de invloed van de write-back cache van de SATA-schijven enorm groot. Zoals reeds gezegd werd schreef Disktesttool voor het bepalen van die minimale randomschrijfsnelheid telkens afwisselend één blok naar het begin en einde van de schijf, waardoor de schijfkop bij een write-through disk-cache zich telkens tussen het begin en einde van de schijf moest verplaatsen. Bij de write-back cache van de SATA-schijven daarentegen werden de data nu pas


17

Figuur 2.9: Random schrijfsnelheid (MB/s); SATA-schijfcache = write-back, SCSI-schijfcache = write-through

weggeschreven naar de schijf wanneer er zich bv. tien blokken van het begin en tien van het einde van de schijf in de cache bevonden. Zodoende was er dan slechts één maximale schijfkopverplaatsing (eerste tien blokken sequentieel naar de schijf schrijven, vervolgens één schijfkopverplaatsing en dan ten slotte de laatste tien blokken ook nog sequentieel schrijven) i.p.v. 19 bij een write-through-cache nodig. Om de gemiddelde random schrijfsnelheid op te meten schreef Disktesttool volledig random een blok naar de schijf. Met behulp van een write-back cache kunnen die schrijfoperaties weliswaar ook enigszins gereorganiseerd worden om zo de schijfkopverplaatsing tot een minimum te beperken, doch niet zo extreem als dat bij de minimale doorvoersnelheid het geval was. In figuur 2.9 zien we dan ook dat de minimale doorvoersnelheid voor de SATA-schijven met write-back-cache nu beter is dan de gemiddelde. Op figuur 2.9 zien we ook dat de minimale random schrijfsnelheid van de Maxtor-schijf groter is dan deze van de Hitachi, blijkbaar wordt bij de Maxtor dus nóg langer gewacht om de data uit de write-back schijfcache naar de schijf weg te schrijven dan dit bij de Hitachi het geval is. Dit veroorzaakt dus een hogere doorvoersnelheid, maar anderzijds zal het dataverlies ook veel

2.6 Conclusies

18

groter zijn moest de schijf ooit eens volledig zonder stroom komen te zitten. Wanneer de cache van de SATA-schijven op write-through wordt ingesteld, dan is er zoals gezegd geen risico op dataverlies, maar zoals we in figuur 2.10 kunnen zien is de doorvoersnelheid dan wel een pak lager. Uit die figuur blijkt tevens dat wanneer alle schijven met write-through schijfcache geconfigureerd zijn, de beste schijf dan effectief ook met de beste random schrijfsnelheid correspondeert.

Figuur 2.10:

Random schrijfsnelheid (MB/s); SATA-schijfcache = write-through, SCSI-

schijfcache = write-through

2.6

Conclusies

De schijftests hebben uitgewezen dat de schijven met de beste specificaties (kortste zoektijd, grootste toerental) ook de beste leessnelheid — zowel sequentieel als random — konden realiseren. Voor het schrijven was dat niet perse het geval, aangezien de SATA-schijven default met write-back caching geconfigureerd waren en de SCSI-schijf default met write-through, waardoor de schrijfsnelheid van de SATA-schijven deze van de SCSI-schijf evenaarde. Write-back caching houdt echter ook een risico op dataverlies in, zodoende is het veiliger om de

2.6 Conclusies

19

cache van de SATA-schijven ook op write-through mode in te stellen. Met een write-through cache scoorde SATA echter beduidend trager dan SCSI. Wanneer alle schijven met write-through cache geconfigureerd worden, dan geldt — analoog aan het lezen — dat de schijf met de beste specificaties ook de beste schrijfsnelheid (zowel sequentieel als random) realiseert. Voor tijdelijke opslag — daarbij vormt dataverlies dus typisch geen al te groot probleem — waarbij er veel geschreven wordt, zijn goedkope SATA-schijven (met write-back cache) dus een zeer goede keuze. Bij databanken met veel random lees- en weinig random schrijfacties — waarbij er typisch zeker geen dataverlies mag optreden — kan daarentegen beter voor SCSI geopteerd worden, indien het budget het toelaat uiteraard.

BESTANDSSYSTEEM-NIVEAU

20

Hoofdstuk 3

Bestandssysteem-niveau

3.1

Inleiding

In het vorige hoofdstuk werd de performantie van de schijf op het laagste niveau gebenchmarkt, en in dit hoofdstuk gaan we nu dieper in op de performantie van het niveau daarboven, het bestandssysteem-niveau. Er werd een brede waaier aan bestandssystemen beschouwd: onder Linux xfs, reiserfs, ext3, ext2 en jfs, en onder Windows ntfs. Om de performantie van die verschillende bestandssystemen na te gaan werd gebruikgemaakt van het programma IOzone (3.263), een geavanceerde filesystem-benchmarktool die toelaat om zowel de sequentiële als random lees- en schrijfsnelheden van een bepaald bestandssysteem op te meten.

3.2

IOZone

Voor de IOZone-benchmarks werd telkens eenzelfde schijf-setup gebruikt, nl. de Seagate-schijf (aangesloten op Athena80) met één partitie die de volledige schijfgrootte besloeg. V´ o´ or elke benchmark werd die partitie dan met het te testen bestandssysteem geformatteerd, onder Linux m.b.v. mkfs en onder Windows met de Disk management; voor alle bestandssystemen werden

3.2 IOZone

21

de defaults gebruikt. Om de prestaties van de verschillende bestandssystemen onderling te kunnen vergelijken werden er m.b.v. Iozone verschillende toegangspatronen beschouwd. Eerst en vooral werd de sequentiële doorvoersnelheid van het bestandssysteem onder de loep genomen, hiertoe werd er — met een transfer-blokgrootte van 128 KB — een bestand van 1 GB naar het bestandssysteem geschreven, en dan ook van het bestandssysteem gelezen. Aangezien dit bestand naar het begin van de schijf geschreven werd (en daar ook van gelezen werd) kon de doorvoersnelheid van het bestandssysteem hier in principe in de buurt komen van de maximale sequentiële lees- en schrijfsnelheden die in hoofdstuk 2 opgemeten werden. In Athena80 (de machine waarop de IOzone-tests uitgevoerd werden) was er 2 GB geheugen aanwezig. Een klein deel van dat geheugen wordt door de processen gebruikt, en het resterende gedeelte stelt het besturingssysteem dan als buffer-cache beschikbaar. Wanneer bestanden van de schijf gelezen of ernaar geschreven worden, dan komen die bestanden ook automatisch in die buffer-cache terecht (op voorwaarde dat er nog voldoende buffer-cache-geheugen beschikbaar is uiteraard). Wanneer we die bestanden nogmaals willen lezen, dan kunnen ze gewoon uit het snelle geheugen gehaald worden, in plaats van nog eens de veel tragere schijf te moeten bezoeken. Dit zal de performantie uiteraard ten goede komen, het spreekt dan ook voor zich dat in toepassingen die veel bestanden moeten serveren een grote buffer-cache uitermate welkom is. Voor onze storage-benchmarks diende de buffer-cache echter zo klein mogelijk te zijn, zodat het wel degelijk de doorvoersnelheid van de schijf (en bestandssysteem) was die opgemeten werd, en niet die van het geheugen. Vlak vóór de sequentiële leestests schreef Iozone immers telkens eerst een 1GB-bestand naar het bestandssysteem, om dan vervolgens dat bestand sequentieel van het bestandssysteem te kunnen lezen. Indien de cache-buffer dus niet tot een minimum gereduceerd werd, dan bevond dat 1GB-bestand zich bij aanvang van de leestest dus volledig in de cache-buffer, zodat we in plaats van de sequentiële doorvoersnelheid van het bestandssysteem dan deze van het geheugen opmaten. Er moest dus een manier gevonden worden om de buffer-cache zo klein mogelijk te maken, en deze werd gevonden in Loadgen, een programma dat ontworpen werd door mijn thesisbegeleider Stijn De Smet, en waarvan de code terug te vinden is in bijlage A. Loadgen alloceert zoveel

3.3 Resultaten IOzone

22

geheugen als de gebruiker dat op de opdrachtlijn opgeeft, en zodoende konden we voor alle benchmarks het beschikbare geheugen steeds tot een vaste, heel kleine hoeveelheid (concreet 100 MB) reduceren. Van die 100 MB werd de meerderheid dan door het Iozone-programma zelf ingenomen, zodat de cache-buffer enorm klein (typisch 15 MB) werd, en er bijgevolg geen gevaar was dat het 1GB-bestand dat IOzone sequentieel van het bestandssysteem las, uit het geheugen zou gelezen worden. Naast het onderzoek van de sequentiële bestandssysteem-toegang werd ook uitgetest hoe goed het bestandssysteem presteerde wanneer er random toegangen — hetzij lezen of schrijven — in één van zijn bestanden plaatsvonden, dit is het gedrag dat optreedt bij een interactieve databank die bijvoorbeeld bij een webshop gebruikt wordt. Iozone maakte hiervoor een bestand van 1 GB aan, om er dan vervolgens op random locaties blokken van 128 KB uit te lezen of naar weg te schrijven. Opnieuw was het belangrijk dat het geheugen tot het minimum (100 MB) beperkt werd m.b.v. Loadgen. Merk op dat dit random toegangspatroon verschillend is van hetgene dat in de schijfniveau-tests uit het vorige hoofdstuk met Disktesttool opgemeten werd. Daar situeerde het random-gedrag zich over de volledige schijfgrootte (73 GB), en moest de schijfkop zich dus typisch over een veel grotere afstand verplaatsen dan dat dit hier (bij een 1 GB-bestand) het geval is. Om die reden is het dan ook niet correct om de random doorvoersnelheden die hier met Iozone opgemeten worden te vergelijken met deze van Disktesttool.

3.3

3.3.1

Resultaten IOzone

Sequentieel lezen

Uit figuur 3.1 blijkt dat de sequentiële leessnelheid van alle Linux-bestandssystemen in de buurt komt van de Max(imale) sequentiële leessnelheid die een niveau lager op het schijf-niveau (in het begin van de schijf) werd opgemeten. De sequentiële leessnelheid van ntfs daarentegen is beduidend lager, doch de ntfs-resultaten dienen met enige voorzichtigheid benaderd te worden. De Linux-bestandssystemen werden immers


23

Figuur 3.1: Sequentiële leessnelheid (MB/s)

allemaal onder hetzelfde besturingssysteem (Linux) gebenchmarkt, waartegenover ntfs onder Windows gebenchmarkt werd, en het uiteraard perfect mogelijk is dat Iozone onder Linux enigszins anders functioneert dan onder Windows. Hiervoor werd contact opgenomen met de maker van Iozone, doch jammergenoeg werd daar geen reactie op ontvangen.

3.3.2

Sequentieel schrijven

Op figuur 3.2 kunnen we zien dat — in tegenstelling tot het sequentieel lezen — nu geen enkel bestandsyssteem de Max(imale) sequentiële schrijfsnelheid (die een niveau lager op het schijfniveau in het begin van de schijf werd opgemeten) evenaart. Bij de benchmarks op het schijf-niveau dienden immers louter blokken data naar de schijf gekopieerd te worden, doch op het bestandssysteem-niveau dienen er naast de eigenlijke data ook nog meta-data (directoryinformatie en dergelijke meer) naar de schijf geschreven te worden. Zonder die meta-data kan het bestandssysteem immers niet weten waar het zijn bestanden op de schijf kan terugvinden. Ext2 heeft de beste sequentiële schrijfsnelheid, wat te verwachten was aangezien ext2 het enige bestandssysteem zonder journaling is. Een journaling-bestandssysteem houdt in een log (journal)


24

Figuur 3.2: Sequentiële schrijfsnelheid (MB/s)

bij welke veranderingen er allemaal aan het bestandssysteem doorgevoerd worden, zodat in het geval van een systeemcrash, het bestandssysteem snel terug naar zijn consistente toestand gebracht kan worden. Bij een non-journaling-filesystem daarentegen moet bij een systeemcrash het volledige bestandssysteem gecheckt worden, wat enorm lang kan duren. Niettegenstaande de iets betere sequentiële schrijfsnelheid wordt ext2 dus best niet in productie-omgeving gebruikt. Verder kunnen we op figuur 3.2 zien dat xfs de beste sequentiële schrijfsnelheid heeft van alle journaling-filesystems. De sequentiële schrijfsnelheden van de verschillende bestandssystemen liggen iets verder uit elkaar dan dat bij het sequentiële lezen het geval was, doch enorm groot zijn de verschillen niet. Opmerkelijk is wel weer de slechte prestatie van ntfs, die nu wel hoger blijkt te zijn dan de sequentiële ntfs-leessnelheid. In principe is dit onmogelijk, aangezien schrijven naar een bestandssysteem (en derhalve schrijven naar een schijf) door de mechanische opbouw van een schijf normaalgesproken altijd trager is dan het lezen van dat bestandssysteem (en schijf). De enige verklaring is dan ook dat het ntfs-bestandssysteem aan zijn gebruiker zegt dat het bestand al volledig weggeschreven is in zijn bestandssysteem terwijl het zich nog ergens in een bestandssysteem-cache bevindt. Opnieuw trekken we hier echter geen al te zware conclusies uit,


25

aangezien Iozone onder Windows wellicht op een andere manier meet dan dit onder Linux het geval is.

3.3.3

Random lezen

Figuur 3.3: Random leessnelheid (MB/s)

Uit figuur 3.3 blijkt dat de random leessnelheden van de Linux-bestandssystemen allemaal heel dicht bij elkaar liggen, en xfs wederom de hoogste doorvoersnelheid realiseert. We merken nogmaals op dat voor deze benchmark de schijfkop zich slechts in een bestand van 1 GB dient te verplaatsen, het is dus volstrekt logisch dat de random leessnelheid die hier opgemeten werd veel hoger is dan deze van op het schijfniveau (waar de schijfkop zich over de volledige schijf moest verplaatsen). Bij ntfs komen we opnieuw tot een opmerkelijke vaststelling, nl. dat de (hoge) random leessnelheid van ntfs (37.6 MB/s) nu maar liefst even snel is als de sequentiële leessnelheid (37.9 MB/s) ervan. De enige mogelijke verklaring hiervoor lijkt dan dat niettegenstaande het 1GBtestbestand sequentieel naar het bestandssysteem weggeschreven wordt, ntfs ervoor zorgt dat het op het schijfniveau gefragmenteerd over de schijf opgeslagen wordt, waardoor een sequentiële leesoperatie op dat bestand dan feitelijk met een random leespatroon op het schijf-niveau


26

correspondeert. Op die manier zouden dan zowel de sequentiële als random leestoegang op het bestandssysteem-niveau met random leestoegang op het schijfniveau corresponderen. Dit is echter slechts een vaag vermoeden, en aangezien de interne structuur van ntfs niet vrijgegeven is doen we daar dan ook geen zekere uitspraken over.

3.3.4

Random schrijven

Figuur 3.4: Random schrijfsnelheid (MB/s)

Uit figuur 3.4 blijkt dat de random schrijfsnelheden wederom vrij dicht bij elkaar liggen, en dat xfs er opnieuw als de beste uitkomt. Wanneer we de random schrijfsnelheden van de bestandssystemen vergelijken met hun random leessnelheden (figuur 3.3), dan komen we tot de opmerkelijke vaststelling dat de schrijfsnelheden beter zijn dan de leessnelheden. Aangezien schrijven naar een schijf inherent trager is dan het lezen ervan, betekent dit dus dat alle bestandsysstemen het weinige beschikbare geheugen van Athena80 (ongeveer 15 MB) als write-back cache benutten. Zodoende kunnen de schrijfoperaties naar de schijf dan uitgesteld worden zodat deze efficiënter — met minder schijfverplaatsingen — kunnen georganiseerd worden, wat dan in een betere doorvoersnelheid van het bestandssysteem resulteert. Uiteraard kan een applicatie er ook voor kiezen om de write-back cache van het bestandssysteem


27

te negeren (en zodoende zekerder te zijn van data-integriteit), door pas een nieuw blok data naar het bestand te schrijven wanneer het vorige blok effectief op de schijf weggeschreven is. Iozone bood de mogelijkheid om die situatie te simuleren: -o Writes are synchronously written to disk. (O SYNC). Iozone will open the files with the ” O SYNC flag. This forces all writes to the file to go completely to disk before returning to the benchmark.” In dat geval kan het bestandssysteem de random schrijfoperaties dan niet meer regroeperen in zijn write-back cache, en zoals we in figuur 3.5 kunnen zien is de doorvoersnelheid dan uiteraard een pak lager dan in het geval waar hij dat wel kon (figuur 3.4). Daarenboven is de random schrijfsnelheid van het bestandssysteem dan uiteraard ook trager dan de random leessnelheid ervan. Op figuur 3.5 zien we dat alle Linux-bestandssystemen weer uiterst dicht bij elkaar liggen, en dat ditmaal reiserfs het best scoort, op de voet gevolgd door xfs.

Figuur 3.5: Random schrijfsnelheid (MB/s) bij synchroon schrijven naar de schijf

De ntfs-doorvoersnelheid is opnieuw opmerkelijk, omdat deze (26.4 MB/s) in tegenstelling tot de Linux bestandssystemen bijna identiek is aan het geval waarbij de write-back cache in principe


28

wél nuttig kan gebruikt worden (27.2 MB/s, zie figuur 3.4). Dit zou dus impliceren dat in tegenstelling tot de Linux-bestandssystemen ntfs niet van een bestandssysteem-write-back-cache gebruikmaakt, doch dit wordt dan weer tegengesproken door de hoge sequentiële schrijfsnelheid van ntfs, die normaalgesproken louter door een bestandssysteem-write-back-cache veroorzaakt kon zijn. Opnieuw trekken we hier geen al te zware besluiten uit.

3.3.5

CPU-verbruik

Figuur 3.6: Gemiddeld CPU-verbruik over de verschillende benchmark-runs (%); hoe lager hoe beter!

Onder Linux kon het CPU-verbruik over de verschillende benchmark-runs m.b.v. /usr/bin/time nauwkeurig worden nagegaan, en zoals we in figuur 3.6 kunnen zien verbruikt xfs het minste CPU. Onder Windows daarentegen kon het CPU-verbruik niet zo accuraat opgemeten worden, zodoende wordt de ntfs-waarde dan ook niet op de grafiek vermeld.

3.4 Conclusies

3.4

29

Conclusies

De IOZone-tests hebben uitgewezen dat de doorvoersnelheden van de verschillende Linux bestandssystemen weliswaar niet zoveel verschillen, maar dat xfs globaal gesproken toch het meest performante is.

RAID-NIVEAU

30

Hoofdstuk 4

RAID-niveau

4.1

Inleiding

In vorige hoofdstukken werd nagegaan hoe goed een individuele harde schijf op het laagste niveau en op het bestandssysteem-niveau presteert. In dit hoofdstuk willen we nu onderzoeken hoe goed een verzameling van harde schijven in een RAID-array nu juist presteert. Zowel de doorvoersnelheden van verschillende hardware-RAID (SCSI en SATA) als van software-RAID (SATA) configuraties worden onder de loep genomen, om vervolgens voor elk RAID-niveau te kunnen concluderen welke van de drie het beste scoort.

4.2

Beschouwde RAID-niveaus

Eerst en vooral geven we een kort overzicht van de beschouwde RAID-niveaus.

4.2.1

RAID1

Bij dit RAID-niveau worden twee — in theorie kunnen het er ook meer zijn doch in de praktijk komt dit nauwelijks voor — schijven gespiegeld”, in die zin dat de data simultaan naar beide ”

4.2 Beschouwde RAID-niveaus

31

Figuur 4.1: RAID1

schijven weggeschreven worden. In dit RAID-niveau is er redundantie aanwezig; wanneer één schijf faalt kunnen de data nl. simpelweg van de resterende schijf gelezen of er naar weggeschreven worden. Bij een tweede schijfcrash wordt deze RAID natuurlijk ook onbruikbaar, zodoende is het erg belangrijk dat een defecte schijf zo snel mogelijk vervangen wordt. Een nadeel van dit RAID-niveau is dat de helft van de storage-capaciteit verloren gaat, meer concreet, als men 160 GB aan data op de RAID1 wil opslaan dan dient de RAID-array over twee schijven van 160 GB te beschikken.


32

Figuur 4.2: RAID0

4.2.2

RAID0

RAID0 werkt met striping, wat betekent dat de bestanden die op de RAID worden opgeslagen in verschillende stripes worden onderverdeeld, die elk naar één schijf worden gestuurd. Zoals we op figuur 4.2 kunnen zien levert RAID0 enerzijds wel de best mogelijke doorvoersnelheid voor een bepaald aantal schijven (gezien alle schijven dataschijven zijn die simultaan benaderd kunnen worden), maar anderzijds biedt het geen enkele vorm van redundantie aan, RAID0 is dan ook geen RAID (Redundant Array of Independent Disks) in de strikte zin van het woord. Het feit dat RAID0 geen redundantie aanbiedt impliceert dus dat van zodra één schijf crasht, de hele RAID-array onbruikbaar wordt, wat dus tevens betekent dat een RAID0-array gemiddeld een hogere kans op falen heeft dan één enkele schijf. Dit RAID-niveau dient dan ook louter gebruikt te worden voor toepassingen waar dataverlies geen al te groot probleem vormt, maar een grote doorvoersnelheid wel mooi meegenomen is (zoals bv. bij temp-directories)


4.2.3

33

RAID5

Figuur 4.3: RAID5

RAID5 werkt net zoals RAID0 met striping, maar in tegenstelling tot RAID0 is dit RAID-niveau nu wél redundant. Net zoals bij RAID0 wordt een bestand in blokken van de vastgelegde stripesize opgesplitst, maar per # Schijven - 1 data-blokken wordt nu een pariteitsblok berekend (d.m.v. exclusieve OR). Deze # Schijven blokken kunnen dan simultaan weggeschreven worden naar het RAID-device. Bij lees-operaties moeten uiteraard enkel de data-blokken gelezen worden. De pariteitsblokken dienen immers louter om bij een schijfcrash de datablokken die zich op de gecrashte schijf bevonden te kunnen reconstrueren. De RAID-controller kan dit doen door de exclusieve OR uit te voeren op het pariteitsblok en alle resterende datablokken van die hoogte (om te verduidelijken wat we met hoogte bedoelen verwijzen we even naar figuur 4.3, waar de A-blokken zich op dezelfde


34

hoogte bevinden, net zoals de B, C en D blokken). Aangezien er zich slechts één pariteitsblok per hoogte bevindt kan RAID5 maximaal één schijfcrash opvangen, vanaf de tweede schijfcrash wordt de RAID5-array onbruikbaar. Aangezien dit RAID-niveau op zijn pariteitsblokken steunt om een gecrashte schijf op te vangen, moet de pariteitsinformatie uiteraard continu up-to-date gehouden worden, bij elke schrijfoperatie moet ze dus aangepast worden. Dit houdt in dat er aan elke schrijfoperatie twee leesoperaties vooraf zullen gaan, zowel het datablok dat aangepast wordt als het pariteitsblok van die hoogte” moeten immers gelezen worden. Vervolgens wordt op basis van het oude datablok, ” het oude pariteitsblok en het nieuwe datablok, het nieuwe pariteitsblok berekend. Uiteindelijk worden het aangepaste datablok en het aangepaste pariteitsblok naar het RAID-device weggeschreven. Een simpele schrijfoperatie komt voor RAID5 dus eigenlijk neer op twee lees- en twee schrijfoperaties. Ten slotte kunnen we op figuur 4.3 eveneens zien dat de pariteitsblokken geroteerd worden. Dit is veel beter dan dat ze allemaal op dezelfde schijf opgeslagen worden, omdat die schijf anders een bottleneck zou worden (bij elke schrijf-operatie moeten de corresponderende pariteitsblokken immers ook aangepast worden).

4.2.4

RAID6

RAID6 is gelijkaardig aan RAID5, maar is nog meer betrouwbaar, aangezien er nu voor elke rij datablokken twee onafhankelijke pariteits-blokken opgeslagen worden op het RAID-device. De ene pariteit kan bv. het product van de datablokken zijn, en de andere bv. de som van de datablokken. Wanneer er dan twee schijfcrashes zouden optreden dan kunnen de verloren datablokken gereconstrueerd worden door het stelsel van de pariteitsvergelijkingen op te lossen. RAID6 kan dus maximaal twee schijfcrashes aan, vanaf drie schijfcrashes wordt een dergelijke RAID-config ook onbruikbaar.


35

Figuur 4.4: RAID6

4.2.5

RAID10

RAID10 is een RAID0 over verschillende RAID1-arrays. Dit RAID-niveau combineert dus de betrouwbaarheid van RAID1 met de goede performantie van RAID0. Dit RAID-niveau kan perfect overweg met schijfcrashes, op voorwaarde dat de crashende schijven niet in dezelfde RAID1-mirrorset vallen. Stel bv. dat we een RAID10-array met 20 schijven gebruiken, die dus uit 10 RAID1-mirrorsets bestaat. Als we geluk hebben, en de crashende schijf ligt telkens in een andere mirrorset, dan blijft de RAID zelfs na 10 schijfcrashes nog functioneren. Anderzijds is het natuurlijk ook mogelijk dat er twee schijven uit dezelfde RAID1mirrorset crashen, en dan wordt de RAID logischerwijze onbruikbaar. Gemiddeld gezien zal een RAID10 dus meer schijfcrashes (minimaal twee) kunnen ondersteunen dan RAID6 (exact twee), maar anderzijds is er bij RAID10 natuurlijk ook minder effectieve datastorage. Voor het

4.3 Beschouwde RAID-configuraties

36

Figuur 4.5: RAID10

bovenstaande voorbeeld kon in RAID10 slechts de capaciteit van tien schijven benut worden, waartegenover er bij RAID6 18 (20 - 2 distribuerende pariteitschijven”) gebruikt zouden kunnen ” worden. Anderzijds kan verwacht worden dat RAID6 voor de writes (door de dubbele pariteit) heel slecht scoort, bij een toepassing die veel schrijfoperaties uitvoert zal RAID10 dan wellicht ook een betere keuze zijn.

4.3

Beschouwde RAID-configuraties

Voor de RAID-tests werd op een nieuwe machine overgeschakeld, Zeus174, waarvan de specificaties terug te vinden zijn in tabel 4.1.


37

CPU

2 x AMD Opteron(tm) Processor 246 (2.0 GHz)

L1 Cache

64 KB instructie- en 64 KB datacache (per CPU)

L2 Cache

1 MB (per CPU)

Moederbord

Iwill DK8ES

Geheugen

2 GB ECC Registered DDR-RAM

OS-disk

Maxtor 6Y080P0 (80 GB)

NIC

eth0 (management): Broadcom BCM5721PCI-E Gigabit Ethernet eth2 (Avalanche-connectie1): Intel(R) PRO/1000 Network Connection eth3 (Avalanche-connectie2): Intel(R) PRO/1000 Network Connection

OS

Debian testing 64-bit

Kernel

2.6.14.2 Tabel 4.1: Specificaties Zeus174

Zoals in de inleiding reeds aangegeven, werden er verschillende RAID-configuraties onderzocht, zowel in software-RAID als in hardware-RAID. Zoals blijkt uit tabel 4.2 duiden we de naam van de RAID-config telkens aan met het RAID-niveau (vóór het koppelteken; RAID0/1/5/6/10 en SINGLE1 ), en het type controller (ná het koppelteken; SCSI, SATA, SOFT). Hardware-SCSIen hardware-SATA-RAID werden hier respectievelijk tot SCSI en SATA afgekort, en softwareSATA-RAID tot SOFT. Merk op dat qua software-RAID geen SCSI onderzocht werd (louter SATA), aangezien het moederbord van Zeus174 niet over onboard-SCSI-sloten beschikte. Als hardware-SCSI-RAID-controller werd een LSI Logic MegaRAID SCSI 320-2E (831 EURO) met de meest recente firmware (514L) gebruikt. De corresponderende driver was reeds aanwezig in de 2.6.14.2-kernel van Zeus174, hij moest enkel nog geactiveerd worden als module (in Device Drivers -> SCSI Device Support -> SCSI low-level drivers). Om de hardware-SATA-RAID te testen werd een Areca ARC-1220 (605 EURO) gebruikt, opnieuw met de meest recent firmware (1.39). De driver voor deze controller was niet aanwezig in de 2.6.14.2-kernel van Zeus174, maar kon op de Areca-website2 wel gedownload worden om dan vervolgens ook als module in de kernel ingeladen te worden. 1

Bij de SINGLE-configuraties wordt telkens één schijf op de beschouwde RAID-controller aangesloten, zodat

we kunnen nagaan hoe goed een bepaalde RAID-array schaalt t.o.v. één schijf. 2 http://www.areca.us/products/html/pcie-sata.htm


38

RAID-config

# Schijven

RBa (KB)

Schijftype

Grootte (GB)

Prijsb ()

/GB

SCSI-SINGLE

1

/

Seagate

73

1457

19.96

SCSI-RAID1

2

64

Seagate

73

2083

28.53

SCSI-RAID5

3

128

Seagate

146

2709

18.55

SCSI-RAID0

3

192

Seagate

219

2709

12.37

SATA-SINGLE

1

/

Hitachi

160

699

4.37

SATA-RAID1

2

64

Hitachi

160

793

4.96

SATA-RAID5

3

128

Hitachi

320

887

2.77

SATA-RAID0

3

192

Hitachi

480

887

1.85

SATA-SING-M

1

/

Maxtor

80

662

8.28

SATA-RAID6

4

128

Maxtor

160

833

5.21

SATA-RAID10

4

128

Maxtor

160

833

5.21

SOFT-SINGLE

1

/

Hitachi

160

94

0.59

SOFT-RAID1

2

64

Hitachi

160

188

1.18

SOFT-RAID5

3

128

Hitachi

320

282

0.88

SOFT-RAID0

3

192

Hitachi

480

282

0.59

SOFT-SING-M

1

/

Maxtor

80

57

0.71

SOFT-RAID6

4

128

Maxtor

160

228

1.43

SOFT-RAID10

4

128

Maxtor

160

228

1.43

Tabel 4.2: Overzicht RAID-configuraties (Stripe-size = 64KB) a b

Afkorting voor RAID-breedte Prijzen van op www.mpl.be, incl. BTW

Naast hardware-RAID (waarbij de RAID-functionaliteit in de hardware van de controller uitgevoerd wordt) bestaat er uiteraard ook software-RAID, die volledig in het besturingssysteem wordt uitgevoerd, en dus geen speciale controller vereist. Voor de software-RAID-testen zouden de SATA-schijven normaalgesproken rechtstreeks op de onboard SATA-sloten van Zeus174’s moederbord aangesloten zijn geworden, doch vermits die SATA-sloten in de nauwaansluitende 6U-omhuizing van Zeus174 onbereikbaar waren, moest voor een alternatieve oplossing geopteerd worden: De toekomstige software-RAID-schijven werden aangesloten op de Areca-controller, en in de Areca-config werden deze schijven dan als Pass Through disk (zie hoofdstuk 2) ingesteld. Daarna moesten de SATA-schijven in het besturingssysteem zelf dan uiteraard nog tot een software-RAID-array geconfigureerd worden, dit gebeurde m.b.v. het Linux-commando mdadm.


39

Schijftype

Code

Zoektijd (ms)

RPM

Buffer (MB)

GBa

Prijsb ()

Seagate

ST373453LW

3.6

15000

8

73

626

Hitachi

HDS722516VLSA80

8.5

7200

8

160

94

Maxtor

6Y080M0

9

7200

8

80

57c

Tabel 4.3: Overzicht schijven gebruikt in de RAID-configuraties uit tabel 4.2 a

Grootte in GB Prijzen van op www.mpl.be, incl. BTW c Prijs van op www.vdhsoft.be b

Voor SOFT-RAID5 was dit bv. mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sda /dev/sdb /dev/sdc Naast hard- en software-RAID hadden we graag ook nog de onboard-RAID-functionaliteit van het Zeus174-moederbord uitgetest, doch onder Linux bleek dit onmogelijk. De onboard NVIDIA RAID-controller van Zeus174 werkte immers louter onder Windows, aangezien het een soort van veredelde Windows-software-RAID was. Zodoende werd deze RAID-configuratie initieel ook nog eens uitgetest onder Windows, doch vermits de metingen vrij inconsistente resultaten gaven en de nadruk van deze thesis bovendien op Linux-storage ligt, werd hier dan ook niet dieper op ingegaan. In wat nu volgt bespreken we kort de verschillende parameters van de onderzochte RAID-configs die in tabel 4.2 weergegeven worden.

# Schijven Het aantal schijven waaruit de RAID-array opgebouwd is. Dit kunnen zowel data-schijven als pariteit-schijven zijn. Merk op dat bij RAID1 maximaal 2 schijven gebruikt konden worden aangezien de beschouwde hardware-RAID-controllers voor dat RAID-niveau geen hoger aantal schijven ondersteunden. RAID-breedte (KB) De hoeveelheid data die volledig simultaan naar het RAID-device kan getransfereerd worden, dit is het product van #data-schijven en de stripe-size. SCSIRAID0 omvat bv. drie data-schijven waarnaar er simultaan kan getransfereerd worden, en met een striping-size van 64 KB levert dat dus in totaal 3 x 64 KB = 192 KB. Bij de onderzochte RAID-configs (zie tabel 4.2) werd — tenzij anders vermeld — steeds voor een stripe-size van 64 KB geopteerd, waardoor de data in blokken van 64 KB met de


40

schijven van de RAIDs werden uitgewisseld. Uiteraard was het praktisch niet haalbaar om voor alle RAID-configs alle mogelijke stripe-sizes uit te testen, zodoende werd ervoor geopteerd om voor alle RAID-configs dezelfde stripe-size te gebruiken, zodat dan een eerlijke vergelijking tussen SCSI-RAID, SATA-RAID en SOFT-RAID kon gemaakt worden. De ideale stripe-size hangt feitelijk af van de applicatie die de storage zal gebruiken. Indien voor een interactieve databank met heel veel korte random schrijfacties (bv. 8 KB) bv. een SCSI-RAID5 gebruikt wordt, dan kunnen we uiteraard beter voor een kleine stripesize opteren. Een grote stripe-size (bv. 128 KB) zou in dit geval voor de writes immers impliceren dat er voor de te schrijven 8 KB eerst 2 x 128 KB (het 128KB-datablok dat de 8 KB omvat en het corresponderende 128KB-pariteitsblok) moet opgehaald worden, om vervolgens m.b.v. de te schrijven 8KB data het nieuwe pariteitsblok te kunnen berekenen. Ten slotte moeten het aangepaste data- en pariteitsblok dan ook nog terug weggeschreven worden. In totaal zou er dus 256 KB opgehaald en 256 KB weggeschreven worden voor een write van slechts 8 KB data. Bij een stripe-size van 4 KB daarentegen zou er voor die 8 KB telkens slechts 12 KB opgehaald en weggeschreven moeten worden (twee data-blokken van 4 KB en één pariteitsblok van 4 KB), wat uiteraard veel efficiënter is. Merk op dat we in het zopas beschouwde voorbeeld er van uitgegaan zijn dat de benodigde 8KB zich telkens in het begin van een RAID-hoogte bevond. Dit is echter niet noodzakelijk het geval, vermits de eerste helft van die 8 KB zich even goed op het einde van een RAIDhoogte en de tweede helft dan op het begin van de volgende RAID-hoogte kan bevinden. In dat geval zouden er dan dubbel zo veel schijftoegangen nodig geweest zijn als waar we van uit gegaan waren. Een databank bestaat typisch uit één of meerdere vrij grote bestanden, waaruit dan korte stukjes gelezen/geschreven worden, die korte stukjes kunnen we dan ook moeilijk gaan uitlijnen. Wanneer er echter veel kleine bestanden van bv. 8 KB op het RAID-device zouden gehuisvest worden, dan kunnen we er in het bovenliggende bestandssysteem wel voor zorgen dat die bestanden goed uitgelijnd worden. Bij xfs bijvoorbeeld kunnen de bestanden gealigneerd worden volgens de stripe-size van het RAID-device, hiervoor worden bij creatie van het xfs-bestandssysteem de switches sunit” en swidth” aangeboden. ” ” Concreet kunnen we bij SCSI-RAID5 bv. m.b.v. het commando mkfs.xfs -d sunit=128,swidth=256 /dev/sda1 (met sunit/swidth uitgedrukt in 512byte-blokken) ervoor zorgen dat de bestanden gealigneerd worden op veelvouden van de

4.4 Omschrijving tests

41

RAID-breedte, zijnde 128 KB. Schijftype Voor de verschillende RAID-configs werden 3 types schijven gebruikt (Seagate, Hitachi en Maxtor), waarvan de specificaties kunnen teruggevonden worden in tabel 4.3. De Seagate is een SCSI-schijf, waartegenover de Hitachi en Maxtor beiden SATA-schijven zijn. Oorspronkelijk was het de bedoeling om alle SATA-RAID-tests met de iets kwalitatievere Hitachi-schijven uit te voeren, doch vermits er hier slechts drie exemplaren van beschikbaar waren en RAID6 en RAID10 minimaal vier schijven vereisen, werd voor de laatstgenoemde RAID-configuraties noodgedwongen voor Maxtor-schijven geopteerd (daarvan waren er wél vier beschikbaar). Grootte (GB) De grootte van het RAID-device. Dit is dus een veelvoud van de schijfgroottes (zie tabel 4.3).

Prijs ( ) De totale prijs van de RAID-configuratie, dus zowel die van de controller (bij de hardware-RAID-configs) als die van de schijven. Bij SCSI-RAID5 bv. kostte de controller 831

en de SCSI-schijven elk 626 , wat een totale kostprijs van 2709 leverde.

/GB De kostprijs per GB RAID-ruimte. Merk op dat deze waarde zal veranderen wanneer er extra schijven aan de RAID-config toegevoegd worden, aangezien de prijs van de controller constant blijft.

4.4

Omschrijving tests

4.4.1

Normaal

Voor de RAID-benchmarks werd opnieuw gebruikgemaakt van Disktesttool (zie hoofdstuk 2). Een RAID-device wordt door Linux immers als een gewoon block-device gezien, dus kon Disktesttool die ook perfect benchmarken. Opnieuw werd het geheugen vóór de aanvang van een test m.b.v. Loadgen (zie bijlage A) telkens volledig gecleared en vervolgens tot 100 MB gereduceerd, om zo te vermijden dat er nog resultaten van vorige tests uit de cache-buffer gelezen konden worden. Disktesttool liet toe om de transfer-blokgrootte op te geven waarmee er data met het RAID-device


42

dienden uitgewisseld te worden, zodat een optimale doorvoersnelheid kon opgemeten worden. Default werden de RAID-devices immers met een blokgrootte van 128 KB aangesproken, en het spreekt voor zich dat dit voor bepaalde RAID-configuraties niet optimaal was. SCSI-RAID0 bv. heeft een RAID-breedte van 192 KB (zie tabel 4.2), wat betekent dat indien men in blokken van 128 KB naar dat RAID-device transfereert, de parallelliteit van het RAID-device maar voor 2/3 benut wordt. In de bespreking van de resultaten zal steeds vermeld worden welke transferblokgrootte gebruikt werd; indien dit toch niet het geval is, betekent het dat bij die tests de default transfer-blokgrootte van 128 KB gebruikt werd.

4.4.2

Degraded

Naast de RAIDs in normale toestand werden ook nog enkele abnormale toestanden opgemeten: degraded en rebuilding mode. Een RAID-array die in degraded (achteruitgezette) mode verkeert3 , bevat een bepaald aantal falende schijven. Het spreekt voor zich dat niet alle RAIDniveaus in degraded mode kunnen terechtkomen. Wanneer er in een RAID0-array bv. een schijf faalt, dan wordt deze RAID-array ogenblikkelijk onbruikbaar, vermits ze over geen enkele vorm van redundantie beschikt. RAID1/5/6/10-arrays daarentegen zijn wel beschermd tegen een bepaald aantal schijffalingen, aangezien ze elk over een bepaalde vorm van redundantie beschikken, daar kan de degraded mode dus wel voorkomen. Bij de RAID-niveaus die twee of meer falende schijven aankunnen (RAID6 en RAID10) werd de degraded mode zowel voor één als twee falende schijven beschouwd. RAID1 in degraded mode is identiek aan een SINGLE-configuratie, en aangezien de performantie van die laatste reeds opgemeten werd, werd dit geval dan ook niet meer expliciet beschouwd. Er zijn verschillende mogelijkheden voor het falen van een RAID-schijf, maar niet alle gevallen kunnen gesimuleerd worden. Het voorkomen van corrupte sectoren op een schijf (wat dus betekent dat de schijf op zijn geheel nog toegankelijk is maar dat er van sommige sectoren geen data meer kunnen gelezen worden) kan bijvoorbeeld onmogelijk gesimuleerd worden zonder de schijf fysiek te beschadigen. 3

Een dergelijke RAID-array produceert typisch een storend geluid om de aandacht van de RAID-beheerder

te trekken. Daarnaast laten bepaalde RAID-controllers ook toe om automatisch een waarschuwingsmail naar de RAID-beheerder te verzenden wanneer de RAID in degraded mode terechtkomt.


43

Een schijffaling die echter wel perfect te simuleren valt, is deze waarbij de stroomvoorziening van een RAID-schijf, of de verbinding met zijn RAID-controller, uitvalt. Hiertoe werd bij een werkende SCSI-array eerst de machine uitgeschakeld, en werd vervolgens van één of twee schijven de stroomconnector verwijderd zodat die schijven dan zogezegd faalden. Wanneer de machine dan terug werd opgestart bevond de RAID zich nu dus in een degraded mode, en konden we m.b.v. Disktesttool de performantie van dat gedegradeerde RAID-device ook nagaan. Bij de SATA-hardware-RAID-arrays daarentegen werden de SATA-kabels die de schijven met de Areca-controller verbonden uit één of twee schijven verwijderd, terwijl de RAID-array upand-running was. Zodoende faalden die schijven ogenblikkelijk. Bij de software-RAID-arrays ten slotte werd een schijf software-matig onbruikbaar gemaakt. Indien we bijvoorbeeld de schijf /dev/sdb uit het software-RAID-device md0 wilden verwijderen, dan gebruikten we daarvoor mdadm --manage --set-faulty /dev/md0 /dev/sdb. Dat de verschillende RAID-devices zich wel degelijk in degraded mode bevonden kon voor de software-RAID in /proc/mdstat geverifieerd worden, en bij de hardware-RAID in de configuratieschermen van de respectievelijke controllers. Tot slot merken we nog op dat de RAID-devices met redundantie default niet de integriteit van hun data verifiëren. Wanneer we bv. met dd rechtstreeks naar één van de schijven van een software-RAID-device schrijven, dan zal het RAID-device dat typisch niet merken, maar het bovenliggende bestandssysteem zal uiteraard wel corrupt raken. De RAID-arrays houden die redundantie immers louter bij om in geval van een schijfcrash de data van de gecrashte schijf te kunnen reconstrueren, maar in normale mode wordt dat nooit gelezen. Desalniettemin kan de beheerder van de RAID-array — indien het RAID-device het toelaat — zo’n integriteitscheck wel manueel opstarten in het configuratie-panel van de RAID-array. Bij RAID1 bv. zullen de blokken van de beide RAID-schijven dan met elkaar vergeleken worden, en bij RAID5 wordt de pariteit van de datablokken van elke RAID-hoogte berekend om vervolgens vergeleken te worden met het pariteitsblok van die hoogte.


4.4.3

44

Rebuilding

Wanneer een bepaalde degraded benchmark voltooid was, werd de machine terug uitgeschakeld, en werd bij de SCSI-RAID-configuraties de stroomverbinding van de voordien falende schijf terug aangekoppeld, en bij de SATA-RAID-configuraties de verbinding naar de RAID-controller terug ingeplugd. Na het rebooten diende(n) de nieuwe schijf(/ven) dan in de configuratiepanels van de RAID-controllers aan de degraded RAID-array toegevoegd te worden. Van zodra dat gebeurd was, werd de rebuild dan automatisch opgestart. Bij de Areca-controller kon dat rebuildproces in de achtergrond uitgevoerd worden, zodat er ondertussen ook een benchmark kon gerund worden in het besturingssysteem. Bij de LSILogic-controller daarentegen was het volgens onze bevindingen niet mogelijk om het rebuildproces in de achtergrond te laten plaatsvinden, waardoor er bij de SCSI-RAID-arrays tijdens het rebuilden geen benchmarks konden uitgevoerd worden. Bij de softwarematige RAID-arrays daarentegen werd (na een reboot) eerst de corrupte schijf uit de array verwijderd (mdadm /dev/md0 -r /dev/sdb) om dan vervolgens terug — als werkende schijf — aan het RAID-device toegevoegd te worden (mdadm /dev/md0 -a /dev/sdb). Van zodra dit gebeurd was, begon de software-RAID-array zich dan automatisch te rebuilden. We merken ten slotte nog op dat de rebuild-rates bij de Areca-controller en de software-RAID niet noodzakelijk identiek waren, zodoende moeten de doorvoersnelheden die tijdens het rebuilden opgemeten werden met enige voorzichtigheid vergeleken worden. Bij de Areca diende de rebuild-rate namelijk uitgedrukt te worden als het percentage tijd dat de controller aan de rebuild-operatie moest besteden (er werd voor 20% geopteerd) en bij de software-RAID diende een minimale4 en maximale5 rebuild-doorvoersnelheid opgegeven te worden (de actuele rebuilddoorvoersnelheid hing dan af van de hoeveelheid aanvragen die het software-RAID-device te verwerken kreeg). 4 5

/proc/sys/dev/raid/speed limit min| 1000 KiB /proc/sys/dev/raid/speed limit max| 200000 KiB

4.5 Resultaten

4.5

4.5.1

45

Resultaten

RAID1

Figuur 4.6: RAID1-doorvoersnelheid (MB/s), transfer-blokgrootte = 128 KB

Uit figuur 4.6 blijkt dat de sequenti¨ ele leessnelheid voor alle RAID-types (SCSI, SATA of SOFT) slechts gelijk is aan deze van één schijf. Hieruit blijkt dus dat de verschillende RAIDcontrollers6 hun leesoperaties niet intelligent over de beide schijven spreiden. In theorie zou bij een 100MB-bestand immers de eerste 50 MB van de eerste en de tweede 50 MB van de tweede schijf kunnen gelezen worden, doch in de praktijk wordt dit dus niet zo ge¨ımplementeerd. Voor het bepalen van de minimale random leessnelheid, switchte Disktesttool telkens tussen het begin en einde van het blockdevice. In theorie zou de RAID0-controller kunnen bijhouden op welke positie de schijfkoppen van zijn beide schijven zich bevinden, zodat hij de leescommando’s die hij te verwerken krijgt dan telkens naar die schijf kan sturen waarvan de schijfkop het dichtst bij de locatie van de uit-te-voeren leesoperatie ligt. Bij deze minimale random read simulatie 6

Voor de eenvoud zullen we hetgeen dat de software-RAID-array beheert verder ook met controller” aanduiden ”

4.5 Resultaten

46

zou hij de leescommando’s voor het begin van het RAID-device dan telkens naar de eerste schijf kunnen sturen (de schijfkop van de eerste schijf bevindt zich dan continu in het begin van die schijf), en die voor het einde van het RAID-device telkens naar de tweede schijf (zodat de schijfkop van de tweede schijf zich dan steeds op het einde van die schijf bevindt). Op die manier moeten de schijfkoppen van de beide schijven zich dan niet telkens van hun begin naar hun einde verplaatsen, en kunnen beiden een soort van sequentiële leesoperatie uitvoeren. Uiteraard zal de doorvoersnelheid die daarmee gerealiseerd wordt gevoelig beter zijn dan in het geval van één schijf (waarbij de schijfkop zich telkens tussen het begin en einde van de schijf moet verplaatsen). In de praktijk blijkt nu dat zowel SCSI als SOFT dit effectief zo implementeren (zij bereiken een random leessnelheid die meer dan dubbel zo groot als die van één schijf is), doch SATA doet dat niet (hij realiseert slechts de doorvoersnelheid van één schijf), wat dus betekent dat zijn controller constant van dezelfde schijf leest. Bij het bepalen van de gemiddelde random leessnelheid daarentegen, las Disktesttool volledig random een bepaald blok van het RAID-device. Dit impliceert dat — niettegenstaande de controller de schijfkoplocaties bijhoudt — de schijfkoppen zich typisch nog zullen moeten verplaatsen vooraleer één van hen tot het lezen kan overgaan. In dat geval is de snelheidswinst t.o.v. één schijf dan ook verwaarloosbaar. Uit figuur 4.6 blijkt dat de sequenti¨ ele schrijfsnelheid van RAID1 iets trager is dan die van één schijf. Dit komt omdat simultaan schrijven naar twee schijven toch net iets trager is dan schrijven naar één schijf. De random schrijfsnelheid scoort ook een heel klein beetje trager dan bij één schijf7 . De optimalisaties die bij het random lezen aan bod kwamen kunnen hier immers niet langer toegepast worden, aangezien er nu telkens naar beide schijven moet geschreven worden.

4.5 Resultaten

47

Figuur 4.7: RAID0-doorvoersnelheid (MB/s), T(ransfer)B(lokgrootte) wordt weergegeven in de legende

4.5.2

RAID0

De sequenti¨ ele leessnelheid zou normaalgesproken drie keer die van één schijf moeten kunnen benaderen, aangezien er simultaan naar drie dataschijven geschreven wordt. Uit figuur 4.7 blijkt dat dit voor alle RAID-configs inderdaad het geval is. Bij het random lezen gebeurt de datatransfer zelf weliswaar ook drie keer zo snel als bij één schijf, doch gezien die datatransfertijd verwaarloosbaar is t.o.v. de tijd die nodig is om de schijfkoppen te verplaatsen, zal de random leessnelheid dat drievoud niet bereiken. Bij de RAID0-benchmarks werd een transfer-blokgrootte van 192 KB gebruikt, zodat elke RAID-schijf simultaan 64 KB (de stripe-size) kon serveren. Aangezien de kost van de datatransfer zoals gezegd verwaarloosbaar is, en we nu bij elke leesoperatie 1.5 keer (192/128) zo veel data als bij de SINGLE-benchmark lezen, kunnen we bijgevolg verwachten dat de random leessnelheid van 7

De schijfcache van de SATA-schijven werd bij deze tests uitzonderlijk op write-through ingesteld, dit verklaart

waarom de doorvoersnelheid van SATA en SOFT hier veel lager is dan die van SCSI (zie hoofdstuk 2)

4.5 Resultaten

48

RAID0 hier iets minder dan 1.5 keer zo snel als die van één schijf zal zijn (iets minder, aangezien de datatransfer nu ook iets langer duurt). Bij een transfer-blokgrootte van 384 KB (waarbij elke schijf simultaan telkens 128 KB leest, wat dus eigenlijk neerkomt op een stripe-size van 128 KB), zou de doorvoersnelheid dan normaalgesproken ongeveer drie keer zo snel als één schijf moeten zijn. In figuur 4.7 zien we dat dit doorgaans bevestigd wordt. Merk op dat de transfer-blokgrootte afhankelijk is van de applicatie die het RAID-device aanspreekt. 128 KB is weliswaar de default transfer-blokgrootte waarmee de kernel met zijn blockdevices communiceert, doch dit aantal kan door de applicatie zelf perfect overridden worden. Een FTP-server bv. zal typisch gebaat zijn bij een grote transfer-blokgrootte. De sequenti¨ ele schrijfsnelheid kan in theorie drie keer zo snel zijn als die van één schijf, en in de praktijk zien we dat ze bij alle RAID0-configs in de buurt komt van dit aantal. Wanneer de cache van de hardware-RAID-controllers daarenboven ook nog eens op write-back i.p.v. op write-through (zie hoofdstuk 2 voor een vergelijking tussen deze cache-modes) wordt ingesteld8 , dan verhoogt de doorvoersnelheid nog, aangezien het schrijven naar de schijven zelf dan nog kan geoptimaliseerd worden in de write-back controller-cache. Merk terloops ook op dat de write-back” of write-through” cache-mode die in de legende van de figuren wordt weergegeven ” ” steeds op de controller-cache slaat. Het lijkt triviaal, maar om alle misverstanden te vermijden, vermelden we toch nog eens dat de keuze tussen een write-through en een write-back controller-cache zich louter stelt in het geval van hardware-RAID (waarbij er zich op de controller een cache bevindt), software-RAID daarentegen beschikt niet over zo’n cache, die bevindt zich dus altijd in write-through-mode als het ware! Wanneer er in de legende van de figuren bijvoorbeeld RAID5 WB degraded” vermeld ” wordt, dan gaan we er vanuit dat de lezer weet dat die WB-cache enkel voor de hardware-RAIDarrays geldt. Ten slotte merken we ook nog op dat een write-back cache uiteraard geen enkele invloed heeft op de leesperformantie. Voor de random schrijfsnelheid kunnen we — analoog aan het random lezen — vaststellen dat een vergroting van de transfer-blokgrootte ook een evenredige vergroting van de doorvoersnelheid tot gevolg heeft. 8

De cache-mode van de controller-cache kan in de configuratiepanels van de respectievelijke hardware-RAID-

controllers gewijzigd worden

4.5 Resultaten

4.5.3

49

RAID5

Normale mode

Figuur 4.8: RAID5-doorvoersnelheid (MB/s), T(ransfer)B(lokgrootte) is in de legende terug te vinden

Uit figuur 4.8 blijkt dat de sequenti¨ ele leessnelheid bij alle RAID5-configs verdubbelt. Dit voldoet aan de verwachtingen, gezien er bij RAID5 per RAID-hoogte simultaan van twee verschillende dataschijven gelezen wordt. Zoals bij de bespreking van RAID0 reeds uitgelegd werd, verwachten we ook hier dat de random leessnelheid louter zichtbaar zal toenemen wanneer de transfer-blokgrootte verhoogd wordt. Op figuur 4.8 wordt dit inderdaad bevestigd. Voor de sequenti¨ ele schrijfsnelheid verwachten we een doorvoersnelheid die slechter is dan die van één schijf. Bij RAID5 moeten bij elke schrijfoperatie immers eerst de veranderende datablokken en het corresponderende pariteitsblok gelezen worden, om vervolgens op basis daarvan het nieuwe pariteitsblok te berekenen, en dat dan — samen met de nieuwe datablokken —

4.5 Resultaten

50

uiteindelijk nog weg te schrijven. Op figuur 4.8 wordt dit voor de hardware-controllers (met write-through cache) inderdaad bevestigd. De software-RAID daarentegen scoorde verbazend genoeg echter beter dan één schijf, waarmee ze dan ook sneller was dan de hardware-RAIDs met write-through cache. Met een write-back cache daarentegen was de doorvoersnelheid van de hardware-RAIDs wel groter dan die van de software-RAID. Analoog aan het sequentieel schrijven, is de random schrijfsnelheid9 van SCSI en SATA weer heel pover wanneer de controller-cache op write-through ingesteld wordt, met write-back cache daarentegen is hun prestatie wel goed.

Degraded mode

Aangezien de testen in normale mode uitgewezen hebben dat een write-back controller-cache essentieel is voor de goede schrijfprestatie van de hardware-RAIDs, bleef de controller-cache van de hardware-RAID-controllers gedurende de degraded en rebuilding testen ook op write-back ingesteld. In normale mode leest de RAID5-controller louter van de twee (roterende) dataschijven, de roterende pariteitsschijf laat hij daarbij ongemoeid. Wanneer RAID5 nu echter in degraded mode terechtkomt (omdat er dus één schijf — die zowel datablokken als pariteitsblokken bevat — faalt), dan heeft dit tot gevolg dat de controller nog steeds (simultaan) van twee schijven moet lezen, waarbij hij soms twee datablokken en soms (in 2/3 van de gevallen) één datablok en één pariteitsblok zal lezen. Daarenboven moet — in geval één van de twee datablokken zich op de falende schijf bevindt — het verloren datablok gereconstrueerd worden door de exclusieve OR op het pariteitsblok en het andere datablok uit te voeren. Aangezien die exclusieve OR normaalgesproken geen dure operatie is kunnen we dus verwachten dat de sequenti¨ ele leessnelheid in degraded mode die van in normale mode zal benaderen. Op figuur 4.9 zien we dat dit voor SATA en SOFT effectief het geval is; bij SCSI is ze iets lager. De random leessnelheid hoeft in degraded mode — om dezelfde reden als bij het sequentiële 9

Bij deze tests werd de schijfcache van de SATA-schijven uitzonderlijk op write-through ingesteld, indien de

controller-cache zich eveneens in write-through mode bevond. Dit verklaart dus waarom de prestatie van SATA en SOFT met write-through controller-cache zo slecht lijkt.

4.5 Resultaten

51

Figuur 4.9: RAID5-doorvoersnelheid (MB/s), voor verschillende modes

lezen — nauwelijks onder te doen voor deze in normale mode. Bij het sequentiële schrijven kunnen we nu echter een hogere doorvoersnelheid verwachten. In normale mode moesten bij elke schrijfoperatie namelijk zowel het aan te passen datablok als het corresponderende pariteitsblok gelezen en geschreven worden. In degraded mode daarentegen moet er nu echter geen pariteitsinformatie meer geschreven worden, aangezien de twee resterende schijven nu beiden niet-roterende data-schijven worden. Zodoende kunnen we verwachten dat in degraded mode de sequenti¨ ele schrijfsnelheid dubbel zo snel als die van één schijf zal zijn. In de praktijk blijkt dit echter enkel bij SATA het geval te zijn. Bij SOFT is de doorvoersnelheid nauwelijks beter dan deze uit normale mode, en bij SCSI is ze zelfs slechter. Bij de random schrijfsnelheid merken we eenzelfde tendens als bij het sequentiële schrijven op.

4.5 Resultaten

52

Rebuilding mode

Voor zowel sequentieel lezen, random lezen, sequentieel schrijven als random schrijven geldt dat de doorvoersnelheden die bereikt werden terwijl de degraded RAID-array aan het rebuilden was, telkens iets lager waren dan in degraded mode. Dit voldoet volledig aan de verwachtingen, aangezien de array in rebuilding mode nog steeds in degraded mode verkeert, en hij daarnaast ook nog tijd aan het rebuilden moet besteden. We merken terloops ook nog eens op dat de doorvoersnelheid van SCSI in rebuilding mode niet kon nagegaan worden, aangezien de SCSIcontroller louter in een BIOS-configuratiescherm kon rebuilden, en we bijgevolg simultaan geen benchmark — waarvoor we ons in het Linux-besturingssysteem moesten bevinden — konden runnen.

4.5.4

RAID6

Normale mode

Figuur 4.10: RAID6-doorvoersnelheid (MB/s)

4.5 Resultaten

53

Bij het lezen van een RAID6-array worden louter de twee roterende dataschijven geraadpleegd, zodoende kunnen we verwachten dat de sequenti¨ ele leessnelheid van RAID6 dubbel zo snel is als die van één schijf.

Uit figuur 4.10 blijkt dat dit voor SATA wel degelijk het geval

is, doch bij SOFT daarentegen scoort ze een pak minder goed (slechts 1.4 keer de SING-Mdoorvoersnelheid). De random leessnelheid zal — analoog aan RAID0 en RAID5 — weer evenredig toenemen met de transfer-blokgrootte. Bij het sequentiële schrijven moet de RAID6-controller naast de twee datablokken telkens ook nog twee pariteitsblokken berekenen en wegschrijven. Theoretisch kunnen we dus verwachten dat een RAID6 bijlange niet de dubbele snelheid van één schijf (die zou bereikt worden indien louter de twee datablokken moesten weggeschreven worden) zal bereiken. Bij SOFT wordt dit bevestigd, die scoort slechts 1.26 keer zo goed als één schijf. De sequenti¨ ele schrijfsnelheid van de SATA blijkt echter verbluffend. Hij scoort namelijk 1.8 keer zo snel als één schijf. Daarmee overklast hij verbazend genoeg ook de sequentiële schrijfsnelheid van zijn equivalente RAID5-config (die eveneens over twee dataschijven, maar slechts over één pariteitsschijf beschikt). Niettegenstaande er bij RAID5 bij elke schrijfoperatie één pariteitsblok minder berekend en weggeschreven moest worden, was zijn sequentiële schrijfsnelheid (69.4 MB/s) toch beduidend lager dan bij RAID6 (118.3 MB/s). De vermoedelijke reden hiervoor is het feit dat de Areca-controller (die de SATA-array beheert) zowat de eerste RAIDcontroller was waarop er RAID6-functionaliteit beschikbaar was, en zodoende zullen de makers ervan die RAID6-functionaliteit wellicht uitermate geoptimaliseerd hebben om de kwaliteit van hun producten in de verf te zetten. Bij het random schrijven ten slotte bleek een write-back cache — net zoals bij RAID5 — belangrijk te zijn voor een goede SATA-prestatie.

Degraded mode

Wanneer RAID6 in degraded mode terechtkomt door één schijfcrash, dan kunnen we verwachten dat de sequenti¨ ele leessnelheid beduidend zal zakken t.o.v. in normale mode. In normale

4.5 Resultaten

54


mode moest er immers louter van de twee dataschijven gelezen worden, in degraded mode daarentegen moest er minimaal van eenzelfde aantal schijven gelezen worden, maar daarenboven moesten de datablokken die zich op de gecrashte schijf bevonden ook nog eens gereconstrueerd worden aan de hand van de corresponderende pariteitsblokken en overige datablokken. Bij twee schijfcrashes moest er één datablok minder in het stelsel van pariteitsvergelijkingen betrokken worden, zodoende zou de degraded performantie bij twee schijfcrashes normaalgesproken net iets beter dan die bij één schijfcrash moeten zijn. Uit figuur 4.11 blijkt dat de sequentiële leessnelheid van SATA-RAID6 in degraded mode inderdaad beduidend lager is dan in normale mode, bij SOFT daarentegen is ze echter beter dan in normale mode, iets wat — gezien de zopas beschreven werking van RAID6 in degraded mode — simpelweg onmogelijk is. Daarenboven is ze bij SOFT maar liefst dubbel zo snel als die van één schijf, het lijkt dus wel alsof de niet-gecrashte schijven dan plots als volledige dataschijven (niettegenstaande ze ook pariteit bevatten) aanzien worden, en het RAID-device derhalve pariteitsinformatie als reële data aan de gebruiker gaat voorschotelen. Wegens tijdsgebrek kon dit niet nader onderzocht worden.

4.5 Resultaten

55

Voor de random leessnelheid verwachten we om dezelfde redenen als bij het sequentiële lezen in degraded mode een performantieverlies t.o.v. normale mode, en dat wordt in figuur 4.11 bevestigd. Bij het sequentiële schrijven verwachten we dat de performantie in degraded mode zal toenemen. In het geval van één schijfcrash moet er nu immers slechts één pariteitsblok (i.p.v. twee in normale mode) berekend en geschreven worden, en bij twee schijfcrashes zelfs geen enkel pariteitsblok meer. Bij twee schijfcrashes zou de sequenti¨ ele schrijfsnelheid van de RAID6 dus normaalgesproken dubbel zo snel moeten zijn als één schijf en bij één schijfcrash dan iets minder. Bij SATA wordt deze verwachting ingelost, SOFT presteert echter barslecht (meer dan dubbel zo traag als in normale mode). Voor de random schrijfsnelheid nemen we dezelfde tendenzen waar als bij het sequentiële schrijven. De SATA presteert zoals verwacht, terwijl de SOFT wederom uitermate slecht presteert.

Rebuilding mode

Zoals verwacht zijn de doorvoersnelheden in rebuilding mode weer iets trager dan in degraded mode, aangezien de controller naast het verwerken van de benchmark-aanvragen ook nog eens bezig is met het rebuilden van de array.

4.5.5

RAID10

Normale mode

Bij RAID10 verwachten we dat de sequenti¨ ele leessnelheid ongeveer dubbel zo snel zal zijn als die van één schijf, aangezien de beschouwde RAID10-arrays telkens opgebouwd waren uit twee RAID1-arrays, en er voordien reeds aangetoond werd dat de sequentiële leessnelheid van RAID1 die van één schijf benaderde, terwijl die van RAID0 evenredig toenam met het aantal dataschijven. Op figuur 4.12 wordt dit voor zowel SATA als SOFT bevestigd. Terloops vermelden

4.5 Resultaten

56

Figuur 4.12: RAID10-doorvoersnelheid (MB/s)

we nog even dat RAID10 voor SCSI niet kon uitgetest worden, aangezien er daar onvoldoende SCSI-schijven voor beschikbaar waren. Voor de random leessnelheid verwachten we — naar analogie met de reeds beschouwde RAIDniveaus — enkel een merkbare stijging t.o.v. één schijf, wanneer de transfer-blokgrootte verhoogd wordt. Dit wordt op figuur 4.12 bevestigd. We verwachten dat de sequenti¨ ele schrijfsnelheid iets minder dan twee keer zo snel als die van één schijf zal zijn. Uit de vorige benchmarks was immers gebleken dat de sequentiële schrijfsnelheid van RAID1 iets trager was dan die van één schijf, en dat die van RAID0 recht evenredig met het aantal dataschijven toenam. Bij SATA blijkt dit inderdaad het geval te zijn, doch SOFT scoort beduidend minder (slechts 1.3 keer zo snel als één schijf). RAID10 werd in de kernel-config van Zeus174 nog als experimental” gecatalogeerd, en wat het sequentiële ” schrijven betreft kunnen we hen daar in elk geval geen ongelijk in geven. Voor de random schrijfsnelheid gelden dezelfde opmerkingen als bij het random lezen.

4.5 Resultaten

57

Degraded mode


Wanneer er één of twee schijfcrashes (in verschillende RAID1-mirrorsets weliswaar) optreden, dan zou dit normaalgesproken geen invloed mogen hebben op de leesperformantie van RAID10, aangezien er dan — net zoals in normale mode — nog steeds louter van twee schijven moet gelezen worden. Op figuur 4.13 zien we dat dit zowel voor de sequenti¨ ele als random leessnelheid bevestigd wordt. Het schrijven zou normaalgesproken iets sneller moeten verlopen, aangezien er nu slechts naar drie (bij één schijfcrash) of naar twee (bij twee schijfcrashes) i.p.v. naar vier schijven (in normale mode) moet geschreven worden. Opnieuw wordt dit zowel voor de sequenti¨ ele als voor de random schrijfsnelheid bevestigd.

4.5 Resultaten

58

Rebuilding mode

De doorvoersnelheden die tijdens het rebuilden opgemeten werden, waren zoals verwacht weer iets trager dan deze uit de degraded mode.

4.5.6

CPU-verbruik

Gedurende alle benchmarks werd het CPU-verbruik ook nauwgezet in de gaten gehouden, en zoals verwacht kon worden, was er louter bij de software-RAIDs enige CPU-belasting merkbaar. De hardware-RAID-controllers beschikten immers zelf over een goede onboard-CPU, die alle RAID-functionaliteit uitvoerde. Bij SOFT-RAID0/1/10 was er ook nauwelijks enige CPU-activiteit te bespeuren, het was eigenlijk louter bij de SOFT-RAID5/6 dat de CPU merkbaar belast werd. Dat is ook logisch, aangezien de pariteit bij die niveaus telkens door de CPU van de machine moet berekend worden. Maar zelfs bij die softwarematige pariteits-arrays werd de CPU nog niet in alle gevallen belast. Bij de random schijftoegang werd de CPU immers nauwelijks belast, aangezien daarbij de verplaatsingstijd van de schijfkoppen telkens heel veel tijd in beslag nam, en het derhalve een hele poos duurde vooraleer de CPU een nieuw pariteitsblok moest berekenen. Het was dus eigenlijk louter bij de sequentiële schijftoegang tot een software-RAID5/6 dat er een merkbare CPU-belasting optrad, meer concreet werd de dual-CPU-setup van Zeus174 bij het sequentiële schrijven voor 5% belast. Bij het sequentiële lezen van een RAID6 in degraded mode was het CPU-gebruik wel gevoelig hoger (rond de 15%), wat natuurlijk perfect verklaarbaar is door het feit dat de CPU daar bij het herstellen van een datablok telkens een stelsel van pariteitsvergelijkingen dient op te lossen.

4.6 Conclusies

4.6

59

Conclusies

In hoofdstuk 2 was reeds aangetoond dat de doorvoersnelheid van één SCSI-schijf gevoelig hoger is dan die van een SATA-schijf, zodoende is het dan ook logisch dat de SCSI-arrays typisch een hogere absolute doorvoersnelheid zullen kunnen realiseren dan de SATA en SOFT. Anderzijds is SCSI natuurlijk ook gevoelig duurder. De keuze voor een bepaalde RAID-config zal uiteraard steeds afhangen van het budget waarover men beschikt, en de doorvoersnelheid die men wil bereiken. In wat nu volgt zullen we dan ook niet aangeven welk RAID-type de hoogste absolute doorvoersnelheid realiseert voor een bepaald RAID-niveau, maar wel of een bepaald RAID-type (SCSI, SATA of SOFT) voldoet aan de doorvoersnelheden die we in theorie van dat RAID-niveau kunnen verwachten. Bij RAID0 schaalden alle RAID-types prima. Aangezien SOFT en SATA dezelfde doorvoersnelheden konden realiseren, en SOFT gevoelig goedkoper is, is de keuze voor SOFT bij dit RAID-niveau dan ook voor de hand liggend. Bij RAID1 was de random leesperformantie van SOFT beter dan die van SATA, en bij de andere schijftoegangen gelijk. Daarenboven is SOFT ook nog eens goedkoper dan SATA, zodoende is de keuze voor SOFT hierbij vanzelfsprekend. De RAID5 performantie van software-RAID is ook heel acceptabel, meer nog, in sommige gevallen scoort hij zelfs beter dan hardware-RAIDs waarvan de controller-cache op write-through ingesteld staat. Bij de hardware-RAID blijkt een write-back cache essentieel te zijn voor een goede performantie. Wanneer men voor write-back-caching opteert, is het echter wel aangeraden om een battery-backup-unit op de controller aan te brengen, om te vermijden dat de controller ooit volledig zonder stroom komt te zitten en er derhalve data — die nog niet weggeschreven waren naar de schijven — verloren gaan. Hardware-RAID5 heeft ook het voordeel dat hij de CPU van de machine volstrekt niet belast, iets wat in een systeem met een hoge CPU-belasting natuurlijk wel mooi meegenomen is. Ten slotte dient ook nog opgemerkt te worden dat in degraded mode SATA beduidend beter presteerde dan SCSI en SOFT. Voor RAID6 presteerde SOFT heel mager, terwijl de performantie van SATA hiervoor prima

4.6 Conclusies

60

was. SCSI kon voor dit RAID-niveau niet onderzocht worden, aangezien de corresponderende RAID-controller geen RAID6-configuraties ondersteunde. Bij RAID10 presteerde SOFT voor het lezen weliswaar even goed als SATA, doch voor het schrijven was SATA gevoelig beter. Opnieuw kon SCSI voor dit RAID-niveau niet onderzocht worden, ditmaal omdat er onvoldoende SCSI-schijven beschikbaar waren.

APPLICATIE-NIVEAU

61

Hoofdstuk 5

Applicatie-niveau

In vorige hoofdstukken werd aan de hand van verschillende benchmarks de doorvoersnelheid van de storage onderzocht. In dit hoofdstuk gaan we nu na of die benchmark-resultaten ook effectief overeenkomen met de doorvoersnelheden van enkele reële applicaties. Zowel FTP als MySQL komen aan bod. Alle applicaties werden geserveerd op Zeus174.

5.1

5.1.1

FTP

Inleiding

Bij FTP wisselen de clients typisch vrij grote bestanden met de FTP-server uit, en daarbij is een hoge FTP-bandbreedte uiteraard essentieel. In deze sectie willen we dan ook nagaan hoe we — voor een brede waaier aan FTP-toegang — een maximale FTP-bandbreedte kunnen realiseren. Het toegangspatroon tot de FTP-server kan vrij uiteenlopend zijn, zodoende hebben we ervoor geopteerd om de twee uitersten te beschouwen: Enerzijds het geval waarbij veel gebruikers allemaal hetzelfde bestand opvragen, en anderzijds de situatie waarbij weinig gebruikers allemaal verschillende bestanden opvragen. In beide gevallen betreffen het relatief grote bestanden. In het eerste geval zal de schijftoegang verwaarloosbaar zijn omdat, eenmaal de FTP-server dat

5.1 FTP

62

ene bestand van zijn storage gelezen heeft, hij het de volgende keren telkens uit zijn buffer-cache1 kan lezen. In het tweede geval daarentegen kan de FTP-server echter helemaal niets uit zijn buffer-cache lezen, aangezien het allemaal verschillende bestanden zijn die gedownload worden. De schijftoegang zal hier dus maximaal zijn, zodoende kunnen we met dit geval een perfect beeld krijgen van de invloed van de verschillende soorten storage op de FTP-data-bandbreedte. Eerst en vooral geven we een korte beschrijving van de testopstelling die gebruikt werd voor beide gevallen, om dan vervolgens elk geval afzonderlijk te bespreken.

5.1.2

Testopstelling

Om een idee te krijgen van de FTP-bandbreedte is er natuurlijk eerst en vooral een FTP-server nodig. Vsftpd, ProFTPD en Pure-FTPd zijn de meest voor de hand liggende keuzes. Vsftpd gaat er prat op om de meest performante en veilige FTP-server op de markt te zijn, en aangezien enkele gerenommeerde FTP-sites als ftp.kernel.org en ftp.debian.org ook van deze FTP-server gebruikmaken, werd dan ook voor hem geopteerd. Zowel vsftpd-2.0.3 als vsftpd-2.0.4 werden gebruikt, beiden hadden eenzelfde performantie. Om de FTP-bandbreedte te meten werd een Spirent Avalanche Reflector gebruikt. Dit geavanceerd meettoestel laat toe om een hoog aantal FTP-clients te simuleren die - al dan niet gelijktijdig - bepaalde bestanden van de FTP-server afhalen. Zoals op figuur 5.1 zichtbaar is wordt de Avalanche door middel van twee Gigabit-poorten met twee Gigabit-poorten van Zeus174 verbonden2 , de Avalanche zal dus maximaal een FTP-bandbreedte van iets minder dan 2 Gbit kunnen opmeten. Daarnaast is de Avalanche d.m.v. een 100Mbit-management-interface verbonden met het testnetwerk, zodat hij dan remote met de Avalanche Commander software kan beheerd worden. Wanneer we op de Avalanche een bepaalde test wilden uitvoeren moesten er via de Avalanche Commander software eerst enkele test-parameters ingesteld worden, waarvan de belangrijkste 1 2

Hierbij wordt de buffer-cache voldoende groot verondersteld De Avalanche beschikt over vier poorten waarvan louter de nulde en de tweede poort gebruikt werden

5.1 FTP

63

Figuur 5.1: Meetopstelling FTP-tests

nu kort besproken worden:

• Eerst en vooral moest uitgedrukt worden hoeveel clients de FTP-server simultaan dienden te belasten. Dit aantal varieerde over de verschillende tests, en soms ook binnen een bepaalde test. • Ten tweede moesten er voor elke test één of meerdere actie-lijsten ingesteld worden, een voorbeeld van zo’n lijst van acties is: 1 ftp://10.0.1.1/1GB1 <MODE=binary> 2 ftp://10.0.1.1/1GB2 <MODE=binary> Concreet zal een bepaalde FTP-client hier met de test-account inloggen via de 10.0.1.1interface van de FTP-server om er vervolgens het bestand 1GB1 van te downloaden. Van zodra de Avalanche die eerste actie voltooid heeft, voert hij dan de tweede actie — het bestand 1GB2 downloaden — uit. Het cijfer in het begin van de regel geeft aan in welke volgorde de actie moet uitgevoerd worden, indien er dus bv. tien regels met een 1 in het begin zouden gestaan hebben dan zouden die tien acties simultaan uitgevoerd geworden zijn. Bij het inloggen op de vsftpd-server diende de FTP-client zich te authenticeren met een systeemgebruiker-account van de FTP-server. Bij correcte authenticatie kwam de FTPclient in de home-directory van die gebruiker terecht, en kon hij daar dan bepaalde bestanden downloaden. Derhalve werd vóór de aanvang van alle FTP-tests de te onderzoeken storage-partitie steeds tot de correcte home-directory gemounted, en werden daar vervolgens enkele bestanden op gecreëerd (m.b.v. dd). In de zopas vermelde actie-lijst logde de

5.1 FTP

64

FTP-client bv. in met de test-account, zodat hij dan in /home/test terechtkwam, en daar vervolgens het bestand 1GB1 uit downloadde. • Ten slotte moesten we elke actie-lijst nog aan een bepaalde Avalanche-poort koppelen. Wanneer we bijvoorbeeld de actie-lijst 1 ftp://10.0.1.1/1GB1 <MODE=binary> aan de nulde Avalanche-poort en 1 ftp://10.0.2.1/1GB1 <MODE=binary> aan de tweede Avalanche-poort koppelden, dan ontving de FTP-server simultaan aanvragen voor gebruikers test (via zijn interface 10.0.1.1) en tast (via 10.0.2.1). In figuur 5.1 kunnen we nog eens nagaan hoe de FTP-server (Zeus174) juist met de Avalanche verbonden is.

Eenmaal alle test-parameters via de Avalanche Commander waren ingegeven, werd het geheugen van de FTP-server (Zeus174) eerst nog eens volledig gecleared, om er zeker van te zijn dat er zich geen restanten van vorige tests meer in de cache-buffer bevonden. Dit clearen werd gerealiseerd door Loadgen (zie bijlage A) meer fysiek geheugen te laten alloceren dan er beschikbaar was, waardoor Loadgen eerst al het geheugen overschreef, om vervolgens zelf te crashen, en derhalve al het geheugen weer tot een initiële toestand te laten verworden. Uiteraard kon hetzelfde effect bereikt worden door de machine telkens te rebooten, doch dat was meer tijdrovend. Bij alle testen werd de TCP-performantie (en zodoende ook de FTP-bandbreedte) gemaximaliseerd door tcp rmem, tcp wmem en tcp mem te verhogen:

sysctl -w net.ipv4.tcp_rmem="4096 1048000 1048000" sysctl -w net.ipv4.tcp_wmem="4096 1048000 1048000" sysctl -w net.ipv4.tcp_mem="196608 512000 768000"

Aangezien de waarden van deze variabelen louter proefondervindelijk opgedreven werden — ze werden verhoogd totdat de FTP-bandbreedte niet meer verbeterde — en niet theoretisch berekend werden, gaan we niet dieper in op de theoretische betekenis ervan, maar verwijzen we voor verdere informatie naar de manpage van tcp3 . 3

http://www.die.net/doc/linux/man/man7/tcp.7.html

5.1 FTP

65

Eenmaal de Avalanche-test dan opgestart was, konden de statistieken van de FTP-clients dan realtime bekeken worden in de Avalanche-commander, er daarnaast konden we op de FTP-server m.b.v. dstat (CPU-verbruik en schijf-doorvoersnelheid) en free (geheugen) ook de prestatie van de FTP-server nauwlettend in de gaten houden. Van zodra de test voltooid was werd er door de Avalanche Commander een test-rapport gegenereerd, dat dan met de Avalanche Analyser software nader kon onderzocht worden. Tot slot merken we nog op dat de FTP-testen beperkt bleven tot het downloaden van data van de FTP-server, aangezien FTP-uploads door de Avalanche niet ondersteund werden. De gebruikte vsftpd-configuratie kan teruggevonden worden in bijlage B.

5.1.3

Veel clients die allemaal hetzelfde bestand downloaden

Eerst en vooral beschouwden we het geval waarbij een grote hoeveelheid FTP-clients allemaal hetzelfde 50MB-bestand opvroegen. Hierbij trad er dus nauwelijks schijftoegang op omdat, eenmaal de FTP-server dat bestand van zijn storage gelezen had en het zich bijgevolg in zijn cache-buffer bevond, hij bij de ettelijke honderden volgende aanvragen van dat bestand zijn storage niet meer moest aanspreken en het bestand simpelweg uit zijn cache-buffer kon lezen. Een realistisch voorbeeld van dit gedrag is de situatie waarbij er op ftp.kernel.org een nieuwe kernel (ongeveer 50 MB) vrijgegeven wordt, en een groot aantal FTP-clients deze kernel simultaan probeert te downloaden.

Omschrijving tests

Eerst en vooral merken we op dat het geheugen van de FTP-server (2GB) bij deze tests volledig vrij gelaten werd, zodat er voldoende ruimte was om enerzijds het 50 MB-bestand te huisvesten (in de cache-buffer dus), en anderzijds nog een grote hoeveelheid FTP-connecties te onderhouden. Er werd gestart met twee simultane FTP-clients, en stelselmatig werd dit aantal in een interval van 600 seconden tot 2000 simultane FTP-clients opgedreven, om vervolgens nog voor 600 seconden op die 2000 simultane FTP-clients te blijven staan. Die meetintervallen werden vrij groot genomen opdat alle FTP-transacties volledig afgewerkt zouden zijn, een belasting

5.1 FTP

66

van 2000 simultane clients die elk 50 MB downloaden impliceerde immers dat de FTP-server ongeveer 100 GB naar de clients moest transfereren. Aangezien initiële tests uitwezen dat de FTP-bandbreedte voor dit soort tests boven de 200 MB/s zat, werd voor een meetinterval van 100000MB/(200MB/s) = 500s — met nog 100s marge — geopteerd. Beide poorten van de Avalanche (zie figuur 5.1) werden gebruikt, zodat er maximaal een FTPbandbreedte van iets minder dan 2 Gbit kon opgemeten worden. Aan elke poort werd een gelijkaardige actie-lijst geassocieerd, enerzijds

1 ftp://10.0.1.1/50MB <MODE=binary>

en anderzijds

1 ftp://10.0.2.1/50MB <MODE=binary>

De tests werden zowel voor de vsftpd in standalone-mode als de vsftpd in inetd-mode uitgevoerd.

Resultaten tests (voor veel gebruikers die allemaal eenzelfde bestand downloaden)

Vsftpd in standalone-mode Eenmaal het 50MB-bestand van de FTP-server-storage gelezen was (wat gezien de minieme grootte van het bestand uiteraard heel snel gebeurde) werd het bestand bij alle volgende aanvragen uit de cache-buffer van de FTP-server gelezen. Derhalve kon de FTP-server dan ook quasi ogenblikkelijk een maximale FTP-data-bandbreedte van 225 MB/s realiseren, en die bandbreedte bleef behouden gedurende de rest van de meting, dus ook bij 2000 simultane FTP-clients. Waarom de FTP-data-bandbreedte nu juist 225 MB/s was, kan vrij eenvoudig verklaard worden. De Avalanche was d.m.v. 2 gigabit-lijnen met Zeus174 verbonden, en 1 Gbit correspondeert met 119 MB/s (1000000000/(8*1048576)). Uiteraard moet er over die lijn echter ook nog header- en FTP-control informatie verstuurd worden. Rekening houdende met 20 IPv4-, 20 TCP-header

5.1 FTP

67

en 38 ethernet overhead bytes4 is de maximale applicatie-bandbreedte dan 113 MB/s (((150040)/(38+1500))*119 MB/s). Voor de FTP-control zal slechts een heel kleine hoeveelheid bandbreedte vereist zijn, zodat we dan op een maximale FTP-data-bandbreedte van ongeveer 112.5 MB/s uitkomen. De dual-CPU-setup van de FTP-server kwam nooit in de problemen, hij bleef zich constant rond de 70% idle situeren, ook wanneer de FTP-server 2000 simultane clients te verwerken kreeg. Geheugen daarentegen was wel essentieel. Naargelang het aantal FTP-clients toenam konden we zien hoe het geheugen meer en meer opgevuld raakte, aangezien er meer en meer simultane connecties moesten geserveerd worden. Er werd dan ook eens gepoogd om stelselmatig een load van maar liefst 10.000 simultane FTP-clients te realiseren, maar bij ongeveer 3.800 simultane FTP-clients crashte de kernel, omdat er door het tekort aan geheugen process swapping problemen optraden.

Vsftpd in inetd-mode Bij vsftpd in inetd-mode konden exact dezelfde trends vastgesteld worden als wanneer de vsftpd in standalone-mode gerund werd. Hiertoe diende het aantal vsftpd-instanties dat binnen een bepaald interval gelaunched mocht worden, wel verhoogd te worden in inetd.conf m.b.v. wait/nowait[.max] 5

5.1.4

Weinig clients die allemaal verschillende bestanden downloaden

In een vorige sectie werd de situatie beschouwd waarin de FTP-clients allemaal eenzelfde bestand van de FTP-server afhaalden, wat impliceerde dat dat bestand na een initiële storage-lezing telkens uit de buffer-cache van de FTP-server kon gelezen worden. In deze sectie zullen we nu nader onderzoeken wat er gebeurt als de verschillende clients allemaal verschillende bestanden van de FTP-server afhalen. In dat geval kan er dus niets uit de buffer-cache gelezen worden, en moet 4 5

http://sd.wareonearth.com/ phil/net/overhead/ The optional ’max’ suffix (separated from ’wait’ or ’nowait’ by a dot) specifies the maximum number of server

instances that may be spawned from inetd within an interval of 60 seconds. When omitted, ’max’ defaults to 40. ftp stream tcp nowait.4000 root /usr/sbin/tcpd /usr/local/sbin/vsftpd

5.1 FTP

68

alles wel van de schijven gelezen worden. Zowel SCSI-RAID0/1/5 als SATA-RAID0/1/5/6/10 (zie tabel 4.2) werden aan dit soort FTP-tests onderworpen, zodat we een uitstekend beeld konden krijgen van de invloed van de verschillende soorten storage op de FTP-bandbreedte.

Omschrijving tests

Bij deze tests werd de RAID-storage telkens in 3 xfs-partities onderverdeeld; er werd voor xfs geopteerd omdat in hoofdstuk 3 bleek dat dit het meest performante bestandssysteem was. De eerste partitie strekte zich uit van het begin van het RAID-device tot 10 GB verder, de tweede van op positie 10GB tot 10GB vóór het einde van het RAID-device, en de derde partitie omvatte de laatste 10 GB van het RAID-device. Vervolgens werden die partities dan telkens gemounted tot respectievelijk /home/test, /home/tist en /home/tast, en in die directories werden dan m.b.v. dd telkens 10 1GB-bestanden aangemaakt. Op die manier konden we voor dit schijfintensief FTP-toegangspatroon twee extremen beschouwen: Enerzijds de situatie waarbij er sequentieel opeenvolgende bestanden van het begin van de FTP-server-storage afgehaald werden (dit correspondeert met de hoogst mogelijke leessnelheid van de storage, zodoende duiden we dit geval verder aan met BESTE”), en anderzijds het ” geval waarbij er simultaan bestanden van de eerste en laatste partitie gedownload werden (dit veroorzaakt het slechtst mogelijke leespatroon tot de storage, zodoende wordt dit geval verder aangeduid met SLECHTSTE”). Uiteraard was het praktisch niet haalbaar om alle mogelij” ke schijfintensieve toegangspatronen te beschouwen, zodoende werd voor deze twee extremen geopteerd.

BESTE

Eerst en vooral beschouwen we het geval waarbij één gebruiker sequentieel tien verschillende 1GB-bestanden - die zich opeenvolgend op de eerste 10GB-partitie van de FTP-server-storage bevinden - van de FTP-server afhaalt. De corresponderende Avalanche-actielijst ziet er als volgt uit:

1 ftp://10.0.1.1/1GB1 <MODE=binary>

5.1 FTP

69

2 ftp://10.0.1.1/1GB2 <MODE=binary> ... 10 ftp://10.0.1.1/1GB10 <MODE=binary>

Zoals reeds eerder vermeld werd kan er bij dit FTP-toegangspatroon — downloaden van allemaal verschillende bestanden — niets uit de cache-buffer gelezen worden, en is de FTP-bandbreedte bijgevolg equivalent met de doorvoersnelheid van de onderliggende storage. In vorige hoofdstukken werd reeds aangetoond dat de sequentiële leessnelheid in het begin van de storage de hoogst mogelijke leessnelheid is. Gezien alle te downloaden 1GB-bestanden zich nu sequentieel in het begin van de FTP-server-storage bevinden zal deze actie-lijst dan ook de hoogst mogelijke FTP-bandbreedte bij dit schijfintensief FTP-toegangspatroon kunnen realiseren. Zodoende werd deze test dan ook van de noemer BESTE” voorzien. ” Voor deze BESTE Avalanche-test was de Avalanche echter dikwijls de bottleneck. Immers, zoals op figuur 5.1 reeds weergegeven werd, is de Avalanche d.m.v. twee Gigabit-poorten met Zeus174 verbonden. In configuraties met een hoog aantal simultane FTP-clients kunnen de verschillende clients weliswaar over de twee Gigabit-lijnen verdeeld worden, doch wanneer er slechts één FTP-client is, dan kan die slechts van 1 lijn gebruikmaken. Dit impliceert dat indien de FTP-server voor dit BESTE geval een FTP-data-bandbreedte van meer dan 1 Gbit zal realiseren, de Avalanche niet de volledige bandbreedte kan opmeten (hij kan immers slechts maximaal 1 Gbit opmeten). Een oplossing hiervoor zou geweest zijn dat zowel de interfaces van de Avalanche als deze van de FTP-server gebonded werden, zodat die ene FTP-client dan één dubbele-gigabit lijn kon gebruiken, maar jammergenoeg bood de Avalanche die mogelijkheid niet. Om te vermijden dat de Avalanche nog langer een bottleneck was werd gepoogd om de Avalancheactielijst enigszins te wijzigen, er werd namelijk nog een extra FTP-client aan de test toegevoegd, die via de andere Gigabit-poort bestanden van de FTP-server afhaalde. Zodoende kon er nu dus een totale FTP-bandbreedte opgemeten worden die groter was dan 1 Gbit. De eerste FTP-client las nu sequentieel vijf 1GB-bestanden van het begin van de eerste FTP-server-storage-partitie, en de tweede simultaan ook vijf 1GB-bestanden van het begin van de tweede partitie (die begint op positie 10 GB). Concreet werd de actie-lijst van de eerste FTP-client nu:

5.1 FTP

70

1 ftp://10.0.1.1/1GB1 <MODE=binary> 2 ftp://10.0.1.1/1GB2 <MODE=binary> 3 ftp://10.0.1.1/1GB3 <MODE=binary> 4 ftp://10.0.1.1/1GB4 <MODE=binary> 5 ftp://10.0.1.1/1GB5 <MODE=binary>

en van de tweede:

1 ftp://10.0.2.1/1GB1 <MODE=binary> 2 ftp://10.0.2.1/1GB2 <MODE=binary> 3 ftp://10.0.2.1/1GB3 <MODE=binary> 4 ftp://10.0.2.1/1GB4 <MODE=binary> 5 ftp://10.0.2.1/1GB5 <MODE=binary>

Echter, aangezien de FTP-server beide clients simultaan serveert, zal hij nu constant tussen de eerste tien en de tweede tien GB van zijn storage moeten switchen. Zodoende verwordt het schijftoegang-gedrag tot een random leesgedrag over de eerste 20 GB van het RAID-device, en zal het dus sowieso een slechtere doorvoersnelheid hebben dan de sequentiële schijftoegang die met het BESTE geval correspondeerde.

Alhoewel de Avalanche nu dus weliswaar een

FTP-data-bandbreedte van meer dan 1Gbit/s kon opmeten, wezen initiële tests uit dat voor die gevallen waar de Avalanche oorspronkelijk een bottleneck was (omdat hij dus geen FTPdatabandbreedtes van meer dan 1 Gbit kon opmeten) die FTP-data-bandbreedte van meer dan 1 Gbit nu niet langer bereikt werd. Er moest dus naar een andere oplossing gezocht worden. Deze oplossing werd dan ook gevonden, maar wel buiten de Avalanche, meer concreet in de tool wget. Met behulp van wget werd dezelfde sequentie van FTP-acties uitgevoerd als deze die in de initiële BESTE Avalanche-actielijst voorkwamen:

for i in ‘seq 1 10‘ do wget -O - ftp://test:[email protected]:/1GB$i > /dev/null done

5.1 FTP

71

Deze wget-commando’s werden uitgevoerd op Zeus174, zodat zowel FTP-clients als FTP-server zich op dezelfde machine bevonden en het FTP-verkeer dus via software over de loopbacknetwerkinterface uitgewisseld werd.

SLECHTSTE

Naast het BESTE geval waarbij één gebruiker sequentieel tien opeenvolgende 1GB-bestanden van het begin van de FTP-server-storage downloadde, werd ook het andere uiterste onderzocht, nl. wanneer twee gebruikers simultaan elk tien sequentiële 1GB-bestanden van de FTP-server ophaalden. Bij de eerste FTP-client waren dit echter bestanden die zich helemaal in het begin van de FTP-server-storage bevonden, waartegenover de tweede FTP-client bestanden wenste die zich helemaal op het einde bevonden. Hiertoe werd voor de eerste FTP-client voor de volgende Avalanche-actielijst geopteerd:

1 ftp://10.0.1.1/1GB1 <MODE=binary> 2 ftp://10.0.1.1/1GB2 <MODE=binary> ... 10 ftp://10.0.1.1/1GB10 <MODE=binary>

En voor de tweede FTP-client voor:

1 ftp://10.0.2.1/1GB10 <MODE=binary> 2 ftp://10.0.2.1/1GB9 <MODE=binary> ... 10 ftp://10.0.2.1/1GB1 <MODE=binary>

Vermits er telkens twee FTP-acties waren met dezelfde prioriteit (het getal op het begin van elke actie-regel; 1,2,...,10), moest de FTP-server continu twee FTP-clients simultaan serveren. Gezien de eerste FTP-client echter bestanden van helemaal vooraan en de tweede van helemaal achteraan de storage wenste, moest de FTP-server constant switchen tussen het begin en einde van zijn RAID-device. Aangezien deze schijftoegang dus het slechtst mogelijke leespatroon representeerde werd dit geval dan ook van de noemer SLECHTSTE” voorzien. ”

5.1 FTP

72

Resultaten tests (voor weinig gebruikers die allemaal verschillende bestanden downloaden)

In figuur 5.2 worden de FTP-data-bandbreedtes voor verschillende soorten storage weergegeven. De SLECHTSTE en BESTE FTP-bandbreedtes fluctueerden gedurende het meetinterval soms enigszins, zodoende wordt op de figuur telkens het gemiddelde over het volledige meetinterval weergegeven. Voor de BESTE bandbreedtes worden telkens zowel de waarden opgemeten met de Avalanche als deze opgemeten met wget weergegeven, aangezien de Avalanche zoals gezegd soms een bottleneck vormde en derhalve de reële FTP-bandbreedte niet kon opmeten6 .

Figuur 5.2: FTP-data-bandbreedte (MB/s) bij weinig gebruikers die allemaal verschillende bestanden downloaden, uitgedrukt voor verscheidene soorten storage

SCSI-SINGLE De BESTE FTP-bandbreedte (73 MB/s) is identiek aan de maximale sequentiële leessnelheid die voor deze RAID-config” in het RAID-hoofdstuk reeds opgemeten ” 6

Wanneer BESTE (Avalanche) gelijk is aan 100 MB/s en kleiner dan BESTE (wget), dan vormt de Avalanche

een bottleneck. In het BESTE geval kon de Avalanche immers slechts 1 gigabit-uplink benutten, die — zoals reeds uitgelegd werd — een FTP-data-bandbreedte van maximaal 112.5 MB/s kon realiseren. Dat die 100 MB/s op de figuur nog een stuk lager is dan de maximale capaciteit van de gigabit-link, komt omdat de waarden op de figuur een gemiddelde zijn over het ganse meetinterval, de FTP-bandbreedte kon dus soms 112.5 MB/s maar dan enige tijd later ook 87.5 MB/s zijn.

5.1 FTP

73

werd. Bij het BESTE FTP-toegangspatroon kwam de schijftoegang zoals gezegd immers neer op een sequentiële lezing van het begin van de FTP-server-storage, en dat wordt op de figuur dan ook bevestigd. Ter herhaling vermelden we eerst nog even dat in het SLECHTSTE FTP-toegangspatroon er twee simultane clients zijn waarbij de ene client bestanden van het begin van de FTPserver-storage en de andere van het einde van de storage ophaalt, zodat de FTP-server constant tussen het begin en het einde van zijn storage moet switchen om de ene client niet langer te moeten laten wachten dan de andere, de clients worden immers simultaan behandeld. In het RAID-hoofdstuk werd er een gelijkaardig random-read patroon beschouwd, maar daarbij werd er telkens slechts 128 KB van de storage gelezen vooraleer er naar het andere uiteinde van de storage overgeschakeld werd. Voor SCSI-SINGLE werd er daarbij een doorvoersnelheid van 11.5 MB/s bereikt. Op figuur 5.2 kunnen we nu zien dat de SLECHTSTE FTP-bandbreedte voor SCSI-SINGLE maar liefst 54 MB/s is, waaruit we kunnen besluiten dat de FTP-server veel grotere blokken dan 128 KB van zijn storage zal lezen, vooraleer hij overschakelt naar het andere uiteinde van zijn storage om daar zijn andere client te serveren. Op die manier zijn er dan niet overdreven veel schijfkopverplaatsingen nodig, wat de doorvoersnelheid uiteraard ten goede komt. SCSI-RAID1 Uit figuur 5.2 blijkt dat zowel de BESTE als de SLECHTSTE FTP-bandbreedte voor deze RAID-config identiek zijn aan deze waarbij SCSI-SINGLE als FTP-serverstorage gebruikt wordt. In het vorige hoofdstuk was reeds gebleken dat de (maximale) sequentiële doorvoersnelheid van SCSI-RAID1 identiek was aan deze van SCSI-SINGLE, en dat wordt hier dan ook bevestigd. SCSI-RAID5 De BESTE (wget) FTP-bandbreedte is hier dubbel zo snel (145/73) als bij SCSISINGLEDISK. Dit bevestigt opnieuw wat de RAID-benchmarks in het vorige hoofdstuk reeds uitgewezen hadden. De SLECHTSTE FTP-bandbreedte is bij SCSI-RAID5 1.3 keer zo snel (71/54) als bij SCSI-SINGLE , en dit bevestigt opnieuw de tendenzen die in het RAID-hoofdstuk waargenomen waren. Bij deze RAID5-config zijn er immers twee dataschijven, waardoor de FTP-server een bepaalde hoeveelheid data van het begin van de schijf (voor de eerste FTP-client) dubbel zo snel kan lezen als bij SCSI-SINGLE, om de schijfkoppen vervolgens

5.1 FTP

74

naar het einde van de storage te verplaatsen en daar opnieuw aan dubbele snelheid een hoeveelheid data voor de tweede FTP-client te lezen. De tijd die nodig is om de schijfkop van het begin van de storage naar het einde van de storage te verplaatsen blijft wel identiek aan deze bij SCSI-SINGLE, dit verklaart dan ook waarom de SLECHTSTE FTP-bandbreedte bij twee datadisks niet verdubbelt maar slechts met een factor 1.3 toeneemt. SCSI-RAID0 Opnieuw worden onze bevindingen uit de RAID-benchmarks van het vorige hoofdstuk bevestigd, uit de figuur blijkt immers dat de BESTE (wget) FTP-bandbreedte voor SCSI-RAID0 — die over drie datadisks beschikt — drie keer zo snel (215/73) is als deze bij SCSI-SINGLE. Bij de SLECHTSTE FTP-bandbreedte nemen we dezelfde tendens als bij SCSI-RAID5 waar, nl. dat de FTP-bandbreedte weliswaar verhoogt (81/54 = 1.5) t.o.v. SCSI-SINGLE, maar dat er geen verdrievoudiging van de bandbreedte optreedt, omdat de verplaatsingstijd van de schijfkop de vertragende factor blijft. SATA-SINGLE De BESTE FTP-bandbreedte (58 MB/s) is identiek aan de maximale sequentiële leessnelheid die voor SATA-SINGLE in het RAID-hoofdstuk opgemeten werd. In het SLECHTSTE geval trad dezelfde situatie als bij SCSI-SINGLE op, wat in een FTP-bandbreedte van 41 MB/s resulteerde (bij SCSI-SINGLE was de verhouding BESTE/SLECHTSTE gelijk aan 73/54 (=1.35), iets slechter dan bij SATA-SINGLE 58/41 (=1.41)) SATA-RAID1 Zowel de BESTE als SLECHTSTE FTP-bandbreedtes zijn gelijk aan deze bij SATA-SINGLE, analoog aan wat we in het RAID-hoofdstuk opgemeten hadden. SATA-RAID5 De BESTE (wget) FTP-bandbreedte is dubbel zo snel (116/58) als bij SATASINGLE, analoog aan wat in het vorige hoofdstuk opgemeten werd. De SLECHTSTE FTP-bandbreedte is 1.7 (70/41) keer zo snel als deze bij SATA-SINGLE. Zoals reeds uitgelegd werd bij SCSI-RAID5, is de SLECHTSTE FTP-bandbreedte van SATA-RAID5 niet dubbel zo snel als bij SATA-SINGLE aangezien de verplaatsingstijd van de schijfkoppen de vertragende factor blijft. Wanneer we de SLECHTSTE FTP-bandbreedte bij SCSI-RAID5 en SATA-RAID5 bekijken, dan komen we tot de opmerkelijke vaststelling dat SATA-RAID5 (70 MB/s) even goed scoort als SCSI-RAID5 (71 MB/s). Een logische verklaring is er echter niet, want aangezien de SCSI-schijven een betere zoektijd hebben dan de SATA-schijven, zouden we

5.1 FTP

75

immers eerder verwachten dat de verplaatsingstijd van de schijfkoppen — die de vertragende factor was bij die SLECHTSTE FTP-toegang — bij de SCSI-setups minder zwaar zou doorwegen en de SLECHTSTE FTP-bandbreedte bij SCSI-RAID5 dus groter zou zijn. Het tegendeel is echter waar. Wellicht leest de FTP-server bij de SATA-storage dus een grotere hoeveelheid data van zijn storage-begin/einde vooraleer hij naar het andere uiteinde van zijn storage overschakelt om daar de andere FTP-client te serveren, zodat de impact van de verplaatsingstijd van de schijfkoppen dan minder groot zal zijn. Dit is echter maar een vermoeden, want het lijkt moeilijk te verklaren waarom de FTP-server bij de SATA-storage langer bij één client zou blijven dan dat bij de SCSI-storage het geval is. SATA-RAID0 Net zoals in het vorige hoofdstuk vastgesteld was, is de BESTE FTP-bandbreedte van SATA-RAID0 drie keer zo snel (174/58) als bij SATA-SINGLE. De SLECHTSTE FTPbandbreedte is 2.1 keer (88/41) zo snel als bij SATA-SINGLE, de verplaatsingstijd van de schijfkoppen is er opnieuw de oorzaak van dat ze niet drie keer zo snel is. We komen opnieuw tot de opmerkelijke vaststelling dat de SLECHTSTE FTP-bandbreedte van SATA-RAID0 (88 MB/s) hier even goed is als bij SCSI-RAID0 (81 MB/s), meer nog, ze is zelfs beter! SATA-SING-M Zoals reeds uitgelegd in het vorige hoofdstuk, werden er voor de SATA-RAID6 en SATA-RAID10 configs Maxtor-schijven gebruikt, zodoende wordt de FTP-bandbreedte bij één Maxtor-schijf als storage ook op de figuur vermeld, om dan te kunnen nagaan hoe goed RAID6/10 schalen t.o.v. één schijf. De BESTE FTP-bandbreedte die bij dergelijke storage gerealiseerd wordt is 56 MB/s, wat overeenkomt met de maximale sequentiële doorvoersnelheid van die schijf die in het vorige hoofdstuk opgemeten werd. SATA-RAID6 Analoog aan de bevindingen uit het RAID-hoofdstuk blijkt ook hier dat de BESTE FTP-bandbreedte dubbel zo goed (111/56) is als bij SATA-SING-M. De SLECHTSTE FTP-bandbreedte is 1.5 keer (59/40) zo snel als deze bij SATA-SINGM, opnieuw is het de verplaatsingstijd van de schijfkoppen die ervoor zorgt dat ze niet dubbel zo snel is. We merken op dat die bandbreedte (59 MB/s) minder goed is dan de SLECHTSTE bandbreedte van SATA-RAID5 (70 MB/s), niettegenstaande beide RAIDconfigs over eenzelfde aantal dataschijven beschikken. SATA-RAID5 bestaat weliswaar uit Hitachi-schijven tegenover Maxtor-schijven bij SATA-RAID6, doch zoals we op figuur 5.2 reeds konden zien, hadden beide schijven ongeveer eenzelfde SLECHTSTE performantie.

5.1 FTP

76

Zodoende kunnen we concluderen dat de Hitachi-schijven voor het SLECHTSTE FTPtoegangspatroon een betere keuze zijn dan de Maxtor-schijven. SATA-RAID10 De BESTE FTP-bandbreedte is dubbel zo snel (113/56) als bij SATA-SINGM; voor de zoveelste keer wordt het corresponderende benchmark-resultaat uit het RAIDhoofdstuk bevestigd. De SLECHTSTE FTP-bandbreedte ten slotte is 1.6 keer zo snel (64/40) als bij SATA-SING-M, opnieuw zorgt de verplaatsingstijd van de schijfkoppen ervoor dat hij niet dubbel zo snel is.

Het CPU-gebruik van de FTP-server werd gedurende de tests continu in de gaten gehouden, maar dat was nergens problematisch, voor alle tests schommelde het rond de 45% idle. De FTP-server beschikte over 2 processors (die dus tesamen voor ongeveer 110/200 belast waren), in een single-CPU machine zou de CPU dus wel degelijk een bottleneck geweest zijn voor dit FTP-gedrag.

5.1.5

Conclusies

Veel gebruikers die allemaal hetzelfde bestand downloaden

Uit deze FTP-tests is gebleken dat bij een grote hoeveelheid simultane FTP-clients nog steeds de maximale FTP-bandbreedte (225 MB/s) kon gerealiseerd worden. Bij een dermate hoog aantal clients was het wel belangrijk dat er voldoende geheugen in de FTP-server aanwezig was.

Weinig gebruikers die allemaal verschillende bestanden downloaden

Eerst en vooral hebben deze FTP-tests uitgewezen dat de doorvoersnelheden die in het vorige hoofdstuk m.b.v. benchmark-tools opgemeten werden, ook effectief met de reële doorvoersnelheden van de storage corresponderen. Daarnaast werd ook vastgesteld dat voor het BESTE FTP-toegangspatroon SCSI-RAID iets beter scoorde dan SATA-RAID. Echter, ten eerste is SCSI-RAID veel duurder, en daarenboven zal

5.2 MySQL

77

het BESTE toegangspatroon in de praktijk ook quasi nooit voorkomen, het is eerder een bovenlimiet voor de mogelijke FTP-bandbreedte. Typisch zullen er immers meerdere FTP-clients zijn, die dan ook nog eens verschillende bestanden downloaden, het SLECHTSTE toegangspatroon is dan ook een veel betere maat voor het te verwachten gedrag. Voor dat SLECHTSTE toegangspatroon konden we vaststellen dat de SATA-RAID-setups (met Hitachi-schijven) de hoogste FTP-bandbreedte konden realiseren. Als we daarnaast ook nog eens de prijs van de SATA-RAID- met de SCSI-RAID-setups vergelijken, dan komen we al snel tot de conclusie dat SATA-RAID de ideale storage voor een FTP-server is!

5.2

MySQL

5.2.1

Inleiding

In tegenstelling tot FTP werkt MySQL typisch met heel korte random schijftoegangen. Uit de benchmarks van de vorige hoofdstukken was reeds gebleken dat de random doorvoersnelheid van SCSI-RAID — zeker voor het lezen — gevoelig beter was dan die van SATA-RAID, dankzij de goede toegangstijd van de SCSI-schijven. In deze sectie willen we nu nagaan of die benchmark-resultaten effectief ook met de realiteit corresponderen. Dit doen we door zowel SCSI-RAID5 als SATA-RAID57 als storage van een MySQL-server te beschouwen, om dan vervolgens die MySQL-server realistisch te belasten. Aan de hand van de prestatie van de MySQL-server kunnen we dan te weten komen of SCSI-RAID nu effectief wel beter scoort dan SATA-RAID voor korte random schijftoegang.

5.2.2

Beschrijving DS2

Om de MySQL-performantie na te gaan werd gebruikgemaakt van een e-commerce test-applicatie van Dell[1], DVD Store Version 2 (DS2) genaamd. DS2 representeert een online DVD store waar gebruikers (nieuw of terugkerend) DVD’s kunnen opzoeken op titel, acteur of categorie, 7

De controller-cache werd in beide gevallen op write-back ingesteld

5.2 MySQL

78

om dan vervolgens al dan niet tot het aankopen van een aantal DVD’s over te gaan. De data worden opgeslagen in een databank naar keuze, en daarnaast voorziet DS2 ook verschillende testprogramma’s die het gebruikersgedrag simuleren en dan vervolgens resultaten over de databankserver-performantie weergeven. Er dient echter wel opgemerkt te worden dat Dell deze benchmark voor een ander doeleinde ontworpen heeft dan waar hij in deze thesis voor gebruikt wordt. Dell wilde met deze benchmark immers aantonen hoe goed MySQL wel scoort in vergelijking met andere databases zoals SQL Server en Oracle, en het spreekt voor zich dat bij een optimale MySQL-configuratie er zo veel mogelijk uit het geheugen zal gelezen worden, en de onderliggende schijven zoveel mogelijk zullen vermeden worden (want de schijftoegang is uiteraard de vertragende factor). Daarvoor dienen de MySQL-buffers dan ook zo groot mogelijk gemaakt te worden, en moet het beschikbare geheugen zo optimaal mogelijk benut worden. Voor deze thesis willen we nu echter juist zo weinig mogelijk data uit het geheugen halen, en zo veel mogelijk schijftoegang hebben, zodat we een goed idee kunnen krijgen van de verschillen tussen SCSI-RAID en SATA-RAID. Derhalve zullen we de MySQL-buffers zo klein mogelijk maken (zie bijlage C), en zullen we het resterende geheugen m.b.v. Loadgen (zie bijlage A) tot het minimum herleiden (concreet: 70 MB; bij minder crashten de testprogramma’s)

5.2.3

Initialisatie DS2-tests

Initieel vereist DS2 de creatie van databank-onafhankelijke data-bestanden (klanten, producten, orders, ...), die men vervolgens in een databank naar keuze dient in te laden. Zowel MySQL, SQL Server als Oracle worden ondersteund, en logischerwijze werd voor MySQL geopteerd. DS2 ondersteunt standaard drie verschillende databank-groottes (10 MB, 1 GB en 100 GB), en vermits er moest vermeden worden dat er veel data kon gecached worden, werd voor de 100 GB databank geopteerd. Het inladen van de data-bestanden in de 100 GB databank verliep echter niet van een leien dakje. Na ettelijke MySQL (en zelfs kernel) crashes gaf het inlaad-proces - met voldoende grote MySQL-buffers (zie bijlage C) en uitschakeling van logging - uiteindelijk geen fouten meer, maar desondanks vlotte het zodanig traag, dat beslist werd om een kleinere (maar toch

5.2 MySQL

79

nog voldoende grote) databank te genereren. Mits wat aanpassingen aan de DS2-build-scripts werd een 12 GB databank operationeel gemaakt, die 20.000.000 klanten, 12.000.000 orders en 1.000.000 producten omvatte. Alle metingen werden op deze databank uitgevoerd.

5.2.4

Omschrijving DS2-tests

Zoals eerder vermeld werden 2 RAID-5-configuraties onderzocht. RAID-5 is, omwille van zijn snelheid en betrouwbaarheid, het meest courante RAID-niveau voor databank-opslag, zodoende was het dan ook logisch om voor onze tests ook voor dit RAID-niveau te opteren. De RAIDdevices werden voor de aanvang van een test telkens opnieuw met xfs geformatteerd — er werd voor xfs geopteerd aangezien in hoofdstuk 3 gebleken was dat dit globaal gesproken het meest performante bestandssysteem is —, en vervolgens van de originele databank voorzien. Daarnaast werd het geheugen ook telkens volledig gecleared m.b.v. Loadgen (zie bijlage A), en vervolgens tot 70 MB gereduceerd. Tot slot bleven gedurende alle metingen de MySQL-buffers minimaal (zie bijlage C), zodat er zo weinig mogelijk uit het geheugen en zo veel mogelijk van de schijven gelezen werd. Om een idee te krijgen van de performantie werden 2 verschillende test-programma’s gebruikt. Enerzijds een simulator die zijn orders rechtstreeks tegen de databank plaatst, en anderzijds één die zijn orders via een web-interface plaatst (er worden PHP-scripts op de Apache2-webserver uitgevoerd die dan de MySQL-server aanspreken). Uiteraard zal de laatstgenoemde simulator trager zijn dan de eerste (vermits hij nog een tussenstap maakt in de webserver), maar anderzijds benadert hij wel beter het gedrag van een realistische webshop. Tot slot nog enkele opmerkingen bij de parameters die bij de DS2-tests gebruikt werden (zie tabel 5.1). De warmup time werd op 0 ingesteld, omdat hoe langer de test gerund wordt, hoe meer MySQL-records er uit het geheugen kunnen gelezen worden, en dat willen we uiteraard niet, gezien we ge¨ınteresseerd zijn in de schijf-performantie. Om diezelfde reden werd ook de run time op de minimale waarde ingesteld.

5.2 MySQL

80

Parameter

Beschrijving

Waarde

n threads

Aantal simultane connecties naar de databank

10 min.

warmup time

Warmup time voordat statistieken worden opgeslagen

0 min.

run time

Run time waarbij statistieken worden opgeslagen

1 min.

pct newcustomers

Percentage nieuwe gebruikers

20

n searches

Gemiddeld aantal zoekacties per order

3

n line items

Gemiddeld aantal items per order

5

think time

Tijd tussen web requests voor elke gesimuleerde gebruiker

5 sec.

virt dir

Locatie webapplicatie (voor webinterface-simulator)

php5a

Tabel 5.1: Parameters DS2-tests a

ds2/mysqlds2/web/php5

5.2.5

Resultaten DS2-tests en conclusies

We vergelijken de prestatie van de verschillende RAID-setups aan de hand van één van de resultaten die de simulatoren weergeven, nl. de gemiddelde wachttijd per order”. Dit is de som ” van alle wachttijden die bij een order optreden: Inloggen/creëeren van een gebruiker, zoeken, aankopen. Voor elk van deze operaties is er databank-toegang vereist, en vermits databanktoegang door onze bijzonder lage hoeveelheid geheugen quasi automatisch ook schijftoegang impliceert, is deze gemiddelde wachttijd per order” een goede maatstaf voor de performantie ” van de onderliggende schijven. Zoals reeds eerder werd opgemerkt, zijn de prestaties van de webinterface-simulator uiteraard een pak trager dan deze van de directaccess-simulator, vermits de eerstgenoemde nog een tussenstation - de webserver - moet passeren. RAID-config

Type Databanktoegang

Na 10s metingen

Na 60s metingen

SCSI-RAID5

Rechtstreeks

1137

407

SATA-RAID5

Rechtstreeks

1785

574

SCSI-RAID5

Webapplicatie

2633

575

SATA-RAID5

Webapplicatie

3076

881

Tabel 5.2: Gemiddelde wachttijd per order, uitgedrukt in ms (hoe lager hoe beter)

5.2 MySQL

81

Uit tabel 5.2 blijkt dat de benchmark-resultaten uit de vorige hoofdstukken effectief met de realiteit corresponderen. Een MySQL-server met SCSI-RAID5 storage scoort immers beter dan één met SATA-RAID5 storage. Anderzijds is de SCSI-RAID5-storage (2709

)

wel een pak

duurder dan de SATA-RAID5 (887 ), zodoende kunnen we dus concluderen dat de SCSI-setup louter de moeite loont in MySQL-configuraties waarbij een snellere uitvoering van de transacties ook een grotere winst impliceert, zoals bv. bij drukbezochte webshops.

CONCLUSIE EN MOGELIJKHEDEN TOT VERDER ONDERZOEK

82

Hoofdstuk 6

Conclusie en mogelijkheden tot verder onderzoek

6.1

Besluiten

We zijn ons onderzoek begonnen op het schijf-niveau, waar we konden vaststellen dat de schijf met de betere specificaties typisch ook de betere doorvoersnelheid kon realiseren. Dankzij hun default write-back-caching was de schrijfsnelheid van de SATA-schijven verbazend goed, wat hen dan ook ideaal maakte voor schrijfintensieve tijdelijke dataopslag. SCSI — met default write-through-caching — was daarentegen de logische keuze bij toepassingen waarbij veel korte random leesoperaties optraden, dataverlies ten allen prijze vermeden moest worden, en de hogere performantie ook een hogere winst tot gevolg had. Vervolgens konden we op het bestandssysteem-niveau waarnemen dat xfs globaal gesproken het meest performante Linux-bestandssysteem was. Op het RAID-niveau kwam het aspect redundantie dan ook aan bod. Voor zowel RAID0, RAID1, RAID5, RAID6 als RAID10 werden telkens zowel hardware-SCSI-RAID (SCSI), hardwareSATA-RAID (SATA) als software-SATA-RAID (SOFT) beschouwd, waarbij SCSI het duurste en SOFT het goedkoopste RAID-type was. Aangezien we voor deze thesis ge¨ınteresseerd waren

6.1 Besluiten

83

in de optimale storage met de beste prijs/kwaliteitsverhouding, waren we dan ook uitermate benieuwd in hoeverre SOFT de doorvoersnelheden van de veel duurdere hardware-RAID-arrays kon evenaren. Voor RAID0 en RAID1 kon SOFT alvast eenzelfde (of zelfs betere!) doorvoersnelheid als SATA realiseren, zodat de keuze voor SOFT voor deze RAID-niveaus dan ook voor de hand liggend was. De RAID5-performantie van SOFT moest enigszins onderdoen voor die van de hardware-RAIDs, aangezien SOFT niet over een write-back controller-cache beschikte. Daarnaast verbruikte SOFT ook CPU van de hostmachine, waardoor bij RAID5 de keuze voor de duurdere hardwareRAID wel te verantwoorden viel. Van de twee soorten hardware-RAID presteerde SCSI zeker voor de random read beduidend beter dan SATA, maar anderzijds was ze ook wel duurder. Wanneer men bv. twijfelt tussen SCSI-RAID5 en SATA-RAID5 voor de opslag van een leesintensieve databank, dient men er dan ook bij stil te staan of een snellere uitvoering van de transacties ook een grotere winst tot gevolg heeft. Voor RAID6 was SATA de ideale keuze, aangezien de prestatie van SOFT voor dit RAID-niveau behoorlijk tegenviel, en SCSI dit RAID-niveau nog niet ondersteunde. Indien het toegangspatroon tot een RAID10 voornamelijk leesacties omvatte, dan bleek SOFT een goede keuze te zijn, doch voor het schrijven scoorde SATA voor dit RAID-niveau beduidend beter. Ten slotte konden we op het applicatie-niveau uiteindelijk vaststellen welke storage de beste prijs/kwaliteit leverde, voor enerzijds FTP en anderzijds MySQL. Bij FTP bleek SATA met write-back caching de meest optimale storage te zijn, aangezien hij ondanks zijn lagere prijs een hogere FTP-bandbreedte dan de corresponderende SCSI-arrays realiseerde. Bij MySQL daarentegen scoorde SCSI-RAID5 met write-back caching beter dan SATA-RAID5 met write-back caching, doch zoals reeds eerder werd opgemerkt, zal de keuze voor het duurdere SCSI enkel maar nuttig blijken wanneer de performantiewinst ook met een geldwinst gepaard gaat (wanneer de diskspace bijvoorbeeld gebruikt wordt voor de databank-opslag van een druk bezochte webshop).

6.2 Verder onderzoek

84

Zodoende hebben we voor verschillende applicaties de storage met de beste prijs/kwaliteitverhouding bepaald, en daarnaast ook rekening gehouden met de redundantie van de data. We kunnen dus concluderen dat het doel van deze thesis gerealiseerd is.

6.2

Verder onderzoek

In deze thesis werd de doorvoersnelheid en redundantie van diskspace binnen één PC beschouwd. Het logische vervolg daarop is het onderzoek van storage gespreid over meerdere PC’s, waarbij dan typisch een gedistribueerd bestandssysteem zal nodig zijn. De vergelijking van dergelijke gedistribueerde bestandssystemen (GPFS, Lustre, ...) zal aan bod komen in een thesis uit het volgende academiejaar.

LOADGEN

85

Bijlage A

Loadgen

zeus174:~/loadgen# cat loadgen.cpp #include

using namespace std;

//don’t forget to disable swap!

char*** largemem[1024];

int main(int argc, char** argv) { int i; int j; int k; int end=atoi(argv[1]); for(i=0;i<end;i++) { largemem[i]=new char**[1024]; for (j=0;j<1024;j++) {

LOADGEN

86

largemem[i][j]=new char*[384]; for (k=0;k<384;k++) { largemem[i][j][k]=new char; } } cout << i << endl; } cout << "press any key to end" << endl; cin >> j; }

VSFTPD: VSFTDP.CONF

87

Bijlage B

Vsftpd: vsftdp.conf

zeus174:~# cat /etc/vsftpd.conf # Run standalone?

vsftpd can run either from an inetd or as a standalone

# daemon started from an initscript. #listen=YES # # Run standalone with IPv6? # Like the listen parameter, except vsftpd will listen on an IPv6 socket # instead of an IPv4 one. This parameter and the listen parameter are mutually # exclusive. #listen_ipv6=YES # # Allow anonymous FTP? (Beware - allowed by default if you comment this out). anonymous_enable=YES # # Uncomment this to allow local users to log in. local_enable=YES # # Uncomment this to enable any form of FTP write command. write_enable=YES #

VSFTPD: VSFTDP.CONF

# Default umask for local users is 077. You may wish to change this to 022, # if your users expect that (022 is used by most other ftpd’s) #local_umask=022 # # Uncomment this to allow the anonymous FTP user to upload files. This only # has an effect if the above global write enable is activated. Also, you will # obviously need to create a directory writable by the FTP user. #anon_upload_enable=YES # # Uncomment this if you want the anonymous FTP user to be able to create # new directories. #anon_mkdir_write_enable=YES # # Activate directory messages - messages given to remote users when they # go into a certain directory. dirmessage_enable=YES # # Activate logging of uploads/downloads. xferlog_enable=YES # # Make sure PORT transfer connections originate from port 20 (ftp-data). connect_from_port_20=YES # # If you want, you can arrange for uploaded anonymous files to be owned by # a different user. Note! Using "root" for uploaded files is not # recommended! #chown_uploads=YES #chown_username=whoever # # You may override where the log file goes if you like. The default is shown # below. #xferlog_file=/var/log/vsftpd.log

88

VSFTPD: VSFTDP.CONF

89

# # If you want, you can have your log file in standard ftpd xferlog format #xferlog_std_format=YES # # You may change the default value for timing out an idle session. #idle_session_timeout=600 # # You may change the default value for timing out a data connection. #data_connection_timeout=120 # # It is recommended that you define on your system a unique user which the # ftp server can use as a totally isolated and unprivileged user. #nopriv_user=ftpsecure # # Enable this and the server will recognise asynchronous ABOR requests. Not # recommended for security (the code is non-trivial). Not enabling it, # however, may confuse older FTP clients. #async_abor_enable=YES # # By default the server will pretend to allow ASCII mode but in fact ignore # the request. Turn on the below options to have the server actually do ASCII # mangling on files when in ASCII mode. # Beware that turning on ascii_download_enable enables malicious remote parties # to consume your I/O resources, by issuing the command "SIZE /big/file" in # ASCII mode. # These ASCII options are split into upload and download because you may wish # to enable ASCII uploads (to prevent uploaded scripts etc. from breaking), # without the DoS risk of SIZE and ASCII downloads. ASCII mangling should be # on the client anyway.. #ascii_upload_enable=YES #ascii_download_enable=YES #

VSFTPD: VSFTDP.CONF

90

# You may fully customise the login banner string: #ftpd_banner=Welcome to blah FTP service. # # You may specify a file of disallowed anonymous e-mail addresses. Apparently # useful for combatting certain DoS attacks. #deny_email_enable=YES # (default follows) #banned_email_file=/etc/vsftpd.banned_emails # # You may restrict local users to their home directories.

See the FAQ for

# the possible risks in this before using chroot_local_user or # chroot_list_enable below. #chroot_local_user=YES # # You may specify an explicit list of local users to chroot() to their home # directory. If chroot_local_user is YES, then this list becomes a list of # users to NOT chroot(). #chroot_list_enable=YES # (default follows) #chroot_list_file=/etc/vsftpd.chroot_list # # You may activate the "-R" option to the builtin ls. This is disabled by # default to avoid remote users being able to cause excessive I/O on large # sites. However, some broken FTP clients such as "ncftp" and "mirror" assume # the presence of the "-R" option, so there is a strong case for enabling it. #ls_recurse_enable=YES # # # Debian customization # # Some of vsftpd’s settings don’t fit the Debian filesystem layout by # default.

These settings are more Debian-friendly.

VSFTPD: VSFTDP.CONF

91

# # This option should be the name of a directory which is empty.

Also, the

# directory should not be writable by the ftp user. This directory is used # as a secure chroot() jail at times vsftpd does not require filesystem # access. secure_chroot_dir=/var/run/vsftpd # # This string is the name of the PAM service vsftpd will use. pam_service_name=vsftpd # # This option specifies the location of the RSA certificate to use for SSL # encrypted connections. rsa_cert_file=/etc/ssl/certs/vsftpd.pem

MYSQL: MY.CONF

92

Bijlage C

MySQL: my.conf

zeus174:~# cat /etc/mysql/my.cnf # This will be passed to all mysql clients # It has been reported that passwords should be enclosed with ticks/quotes # escpecially if they contain "#" chars... # Remember to edit /etc/mysql/debian.cnf when changing the socket location. [client] port

= 3306

socket

= /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs # The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed. [mysqld_safe] socket


nice

= 0

[mysqld] # # * Basic Settings

MYSQL: MY.CONF

93

# user

= mysql

pid-file

= /var/run/mysqld/mysqld.pid

socket


port

= 3306

basedir

= /usr

datadir

= /areca/varlibmysql

tmpdir

= /areca/tmp

language

= /usr/share/mysql/english

skip-external-locking # # For compatibility to other Debian packages that still use # libmysqlclient10 and libmysqlclient12. old_passwords

= 1

# # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. bind-address

= 127.0.0.1

# # * Fine Tuning # key_buffer

= 0 #16M 256M

max_allowed_packet

= 16M

thread_stack

= 128K

# # * Query Cache Configuration # query_cache_limit

= 1048576

query_cache_size

= 0 #16777216 134217728

query_cache_type

= 1

# # * Logging and Replication

MYSQL: MY.CONF

94

# # Both location gets rotated by the cronjob. # Be aware that this log type is a performance killer. #log

= /var/log/mysql.log

#log

= /var/log/mysql/mysql.log

# # Error logging goes to syslog. This is a Debian improvement :) # # Here you can see queries with especially long duration #log-slow-queries

= /var/log/mysql/mysql-slow.log

# # The following can be used as easy to replay backup logs or for replication. #server-id

= 1

#log-bin #expire-logs-days #max_binlog_size

= /var/log/mysql/mysql-bin.log = 20 = 104857600

#binlog-do-db

= include_database_name

#binlog-ignore-db

= include_database_name

# # * BerkeleyDB # # According to an MySQL employee the use of BerkeleyDB is now discouraged # and support for it will probably cease in the next versions. skip-bdb # # * InnoDB # # InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/. # Read the manual for more InnoDB related options. There are many!

ft_min_word_len = 3 ft_stopword_file =

MYSQL: MY.CONF

95

#key_buffer, query_cache_size ook terug aanpassen read_buffer_size = 0 #2097144 read_rnd_buffer_size = 0 #4194288 myisam_sort_buffer_size = 0 #67108864 innodb_buffer_pool_size = 0 #1363148800 innodb_additional_mem_pool_size = 0 #20971520 innodb_log_buffer_size = 0 #8388608

# * Security Features # # Read the manual, too, if you want chroot! # chroot = /var/lib/mysql/ # # If you want to enable SSL support (recommended) read the manual or my # HOWTO in /usr/share/doc/mysql-server/SSL-MINI-HOWTO.txt.gz # ssl-ca=/etc/mysql/cacert.pem # ssl-cert=/etc/mysql/server-cert.pem # ssl-key=/etc/mysql/server-key.pem

[mysqldump] quick quote-names max_allowed_packet

= 16M

[mysql] #no-auto-rehash # faster start of mysql but no tab completition

[isamchk] key_buffer

#

= 16M

MYSQL: MY.CONF

# * NDB Cluster # # See /usr/share/doc/mysql-server-*/README.Debian for more information. # # The following configuration is read by the ndbd storage daemons, # not from the ndb_mgmd management daemon. # # [MYSQL_CLUSTER] # ndb-connectstring=127.0.0.1

96

BIBLIOGRAFIE

Bibliografie

[1] DVD Store Version 2, http://linux.dell.com/dvdstore/

97

LIJST VAN FIGUREN

98

Lijst van figuren

2.1

Toegangstijd (ms) van bepaalde schijven, opgemeten met verschillende disktools

7

2.2

Opbouw van een schijf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3

Maximale sequentiële doorvoersnelheid (MB/s) van de Hitachi-schijf aangesloten op verschillende controllers, opgemeten met onafhankelijke disktools . . . . . . .

11

2.4

Sequentiële leessnelheid (MB/s) van de beschouwde schijven . . . . . . . . . . . .

12

2.5

Random leessnelheid (MB/s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.6

Toegangstijd (ms) van de beschouwde schijven; hoe lager hoe beter! . . . . . . .

14

2.7

Sequentiële schrijfsnelheid (MB/s); SATA-schijfcache = write-back en SCSI-schijfcache = write-through

2.8

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Sequentiële schrijfsnelheid (MB/s); SATA-schijfcache = write-through en SCSIschijfcache = write-through . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.9

14

16

Random schrijfsnelheid (MB/s); SATA-schijfcache = write-back, SCSI-schijfcache = write-through

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.10 Random schrijfsnelheid (MB/s); SATA-schijfcache = write-through, SCSI-schijfcache = write-through

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

LIJST VAN FIGUREN

99

3.1

Sequentiële leessnelheid (MB/s) . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.2

Sequentiële schrijfsnelheid (MB/s) . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.3

Random leessnelheid (MB/s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.4

Random schrijfsnelheid (MB/s) . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.5

Random schrijfsnelheid (MB/s) bij synchroon schrijven naar de schijf . . . . . . .

27

3.6

Gemiddeld CPU-verbruik over de verschillende benchmark-runs (%); hoe lager hoe beter! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.1

RAID1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.2

RAID0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

4.3

RAID5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.4

RAID6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.5

RAID10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.6

RAID1-doorvoersnelheid (MB/s), transfer-blokgrootte = 128 KB . . . . . . . . .

45

4.7

RAID0-doorvoersnelheid (MB/s), T(ransfer)B(lokgrootte) wordt weergegeven in de legende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.8

47

RAID5-doorvoersnelheid (MB/s), T(ransfer)B(lokgrootte) is in de legende terug te vinden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

RAID5-doorvoersnelheid (MB/s), voor verschillende modes . . . . . . . . . . . .

51

4.10 RAID6-doorvoersnelheid (MB/s) . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4.11 RAID6-doorvoersnelheid (MB/s), voor verschillende modes . . . . . . . . . . . .

54

4.9

LIJST VAN FIGUREN

100

4.12 RAID10-doorvoersnelheid (MB/s) . . . . . . . . . . . . . . . . . . . . . . . . . .

56

4.13 RAID10-doorvoersnelheid (MB/s), voor verschillende modes . . . . . . . . . . . .

57

5.1

Meetopstelling FTP-tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

5.2

FTP-data-bandbreedte (MB/s) bij weinig gebruikers die allemaal verschillende bestanden downloaden, uitgedrukt voor verscheidene soorten storage . . . . . . .

72

LIJST VAN TABELLEN

101

Lijst van tabellen

2.1

Specificaties Athena80 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2

Overzicht van de schijven gebruikt tijdens de schijf-niveau-tests . . . . . . . . . .

5

2.3

Overzicht belangrijkste schijfkarakteristieken die de disktools kunnen opmeten . .

5

4.1

Specificaties Zeus174 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.2

Overzicht RAID-configuraties (Stripe-size = 64KB) . . . . . . . . . . . . . . . . .

38

4.3

Overzicht schijven gebruikt in de RAID-configuraties uit tabel 4.2 . . . . . . . .

39

5.1

Parameters DS2-tests

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

5.2

Gemiddelde wachttijd per order, uitgedrukt in ms (hoe lager hoe beter) . . . . .

80

Experimentele karakterisatie van doorvoersnelheid en redundantie van relatief goedkope en kleinschalige diskspace

Recommend Documents