Disken worden steeds groter en dat is een gegeven waarmee iedereen bekend is. Onlangs is er een rapport verschenen over de mogelijkheid om 10 TB te plaatsen op een vierkante inch. We zitten dus nog niet echt vast als het gaat om capaciteit. Grotere disken brengen voordelen mee, maar zeker ook nadelen. Dat laatste wil ik in dit artikel onder de aandacht brengen.
Kenmerken grote disken:
– Veel opslagcapaciteit 1TB, 1.5TB en recentelijk 2TB
– Meestal 3,5" form factor (Large Form Factor)
– Meestal 7200 RPM
– Meestal SATA gebaseerd
– Hoge sequentiële doorvoersnelheid (60MB/s)
– Lage random performance ~40-60 I/O per seconde
Iedereen is ook bekend met de voordelen van grotere disken:
– Minder kosten per GB/TB
– Minder externe disk kabinetten nodig
– Meer schaalbaarheid in TB/systeem
– Minder warmte ontwikkeling en stroom (groen)
– Salesverkopen op basis van GB/TB (makkelijk)
Wat zijn dan de nadelen van grote disken? In eerste instantie is random access een hele belangrijke. Gaan we namelijk uit van sequential access (denk aan video, imaging, logs, back-up to disk) dan zijn grote disken eigenlijk het beste. Maar gaan we kijken naar fileservers, databases of mailservers, dan is random access dominant. Random access verkeer vraagt een hoge I/O rate. In deze omgevingen zijn grote disken absoluut af te raden.
Average I/O per disk:
7200 RPM disk : 40-60 I/O per seconde
10.000 RPM disk : 120 I/O per seconde
15.000 RPM disk : 150 I/O per seconde
Zoals bovenstaand overzicht laat zien heeft men tot drie keer een 7200 RPM disk nodig om tot dezelfde I/O performance te komen als een 10.000 RPM disk. Bij een 15.000 RPM disk is dit verschil zelfs tot vier maal. Naast deze verschillen zijn er echter nog een aantal wezenlijke zaken:
-10.000 en 15.000 disken zijn pre-dominant SAS/SCSI/FC disken, hebben sterkere magneten, intelligente servo's en firmware en meer buffers.
– Sommige grote SATA-disken koelen zichzelf door de host te 'knijpen' waardoor ze nog trager kunnen worden.
– Garantieverschillen: SAS/SCSI/FC disken drie tot vijf jaar, SATA meestal een jaar.
– Het effect van RAID op het aantal disken voor een bepaalde performance.
– Lees- en schrijfverhouding.
Vooral het verschil tussen het aantal disken dat nodig is voor opslag (GB) en performance kan enorm zijn. Zo kan een storageconfiguratie die goed gesized is (op basis van performance dus) met 15.000 RPM disken goedkoper zijn dan dezelfde configuratie met 1TB disken.
Voorbeeld van het verschil tussen capaciteit en performance gebaseerde disk berekeningen:
Microsoft Exchange 2003 storage sizing (werkt NIET voor Exchange 2007!)
Parameters :
1500 mailboxes van 100 MB, twee storage groups, twee databases. 66 procent read.
Dit genereert de volgende gegevens:
Peak I/O = 900 I/O (vanuit de server)
RAID1+0 = 1180 I/O (op het storagesysteem)
RAID 5 = 1782 I/O (op de storagesysteem)
Sizing op basis van 1TB 7200 RPM disken.
Totale storage nodig: 360 GB
RAID 1+ 0 Capaciteit gebaseerd: twee disken
Performance gebaseerd : dertien disken
RAID 5 Capaciteit gebaseerd: drie disken
Performance gebaseerd : twintig disken
Sizing op basis van 300 GB 15.000 RPM disken.
RAID 1+ 0 Capaciteit gebaseerd: vier disken
Performance gebaseerd : zeven disken
RAID 5 Capaciteit gebaseerd: drie disken
Performance gebaseerd : tien disken
Uit bovenstaand voorbeeld blijkt het grote gat tussen capaciteit en performance in relatie tot RAID level en disk type. In het ergste geval (RAID 5 en 7200 RPM disken) is het verschil maar liefst zeventien disken!
Het tweede probleem ligt in bescherming van de data. Het eigenlijke probleem is de hoeveelheid data die gereconstrueerd moet worden na uitval van een grote disk en de daaraan verbonden rebuild tijden. Dit in combinatie met zwaar beladen storagesystemen levert zeer lange hersteltijden van soms wel een tot twee weken op! In de toekomst wordt dit naar alle waarschijnlijkheid alleen maar langer. Het effect van deze lange rebuild-tijden is natuurlijk een groter risico op dataverlies, immers een disk failure tijdens de rebuild kan dataverlies opleveren. Storagefabrikanten moeten dit probleem tackelen. Hierin onderscheiden zich twee mogelijkheden:
1. Sneller rebuilden (rebuild priorities en CPU power)
2. RAID-levels met meer protectie
Voornamelijk op punt twee zijn er al volop mogelijkheden zoals RAID 6, RAID 10, RAID 50 en RAID 60.
De laatste twee worden nu steeds meer geïmplementeerd in storagesystemen en bieden bij RAID 50 een disk failure per RAID 5 set x het aantal sets en bij RAID 60 zelfs twee disk failures per RAID 6 set x het aantal sets.
Voorbeeld
RAID 60 verdeelt over 64 disken: 8x een RAID 6 set van acht disken waarover gestriped wordt. In iedere RAID 6 set kunnen twee disken tegelijk defect raken. In best case dus zestien disken! In worst case zijn dat er twee binnen dezelfde RAID 6 set. Een derde zou dataverlies opleveren. Dit betekent ook dat je goed moet kijken welke disken je uitkiest bij het aanmaken van een RAID-configuratie (denk aan welke disken in welke enclosures en verspreidt over verschillende bussen). Gelukkig zijn SAS-disken tegenwoordig dual ported (met twee gescheiden bussen aangesloten), waardoor er op dat gebied wat meer beschikbaarheid is.
Conclusie
Voor statische data of sequential access is een oplossing met grote disken een goede oplossing. Vaak zelfs de best presterende en goedkoopste oplossing! Voor random access en online data zijn grote disken echter niet geschikt en haalt men veel meer uit kleinere disken met een hogere RPM.
Ik vind het bovenstaande rekenvoorbeeld niet reeel. Er is gegeven dat er 360 GB totale storage nodig is. In dat geval is gebruik maken van 1TB disks niet zinnig, en komen de 300 GB schijven automatisch beter uit de vergelijking.
Een voorbeeld met bijvoorbeeld 1800 GB benodigde ruimte zou beide schijfgrotes optimaal benutten, waardoor de vergelijking eerlijker wordt. Dan kom je qua capaciteit op het volgende uit:
Sizing op basis van 1TB 7200 RPM disken.
RAID 1+0 Capaciteit gebaseerd: vier disken
RAID 5 Capaciteit gebaseerd: drie disken
Sizing op basis van 300 GB 15.000 RPM disken.
RAID 1+0 Capaciteit gebaseerd: twaalf disken
RAID 5 Capaciteit gebaseerd: zeven disken
Zelf zou ik niet zo snel een RAID 5 met zeven schijven gebruiken, omdat de kans op storingen te groot wordt, maar het kan wel.
De performance gegevens kan ik zo niet berekenen, dus als iemand dat nog zou kunnen doen… Ik ben wel benieuwd wat daar uit komt.
Beste sander,
De 360 GB komt direct voort uit de informatie ingegeven in het bereken model. Ik heb hiervoor gekozen omdat een exchange server met 1500 gebruikers een omgeving is waarmee veel lezers zich kunnen identificeren.
Eigenlijk is jouw reactie precies hetgene waarvoor ik waarschuw: mensen kijken niet naar de benodigde performance, maar meer naar de capaciteit.
Zou je zoals in jouw voorbeeld met 1800GB gaan werken moet je als exchange omgeving gaan praten over 9000 mailboxen. Het probleem is dus, meer data = meer users = meer I/O = meer disken nodig.
Parameters :
9000 mailboxes van 100 MB, twee storage groups, twee databases. 66 procent read.
Dit genereert de volgende gegevens:
Peak I/O = 5400 I/O (vanuit de server)
RAID1+0 = 7128 I/O (op het storagesysteem)
RAID 5 = 10692 I/O (op de storagesysteem)
Totale storage nodig: 2000 GB
Sizing op basis van 1TB 7200 RPM disken.
RAID 1+ 0 Capaciteit gebaseerd: 3 disken
Performance gebaseerd : 79 disken
RAID 5 Capaciteit gebaseerd: 3 disken
Performance gebaseerd : 119 disken
Sizing op basis van 300 GB 15.000 RPM disken.
RAID 1+ 0 Capaciteit gebaseerd: 14 disken
Performance gebaseerd : 40 disken
RAID 5 Capaciteit gebaseerd: 8 disken
Performance gebaseerd : 59 disken
Je ziet dus de relatie tussen performance en capacity:
Voor de RAID5 oplossing met 7200 RPM disken een verschil van 116 disken. Vandaar ook het stukje over extra bescherming met RAID50 en RAID60. Deze lossen het gestelde probleem van RAID5 op.
I/o performance discussies zijn waarschijnlijk de lastigste die er zijn. Want bij het tunen van een infrastructuur heb je te maken met server i/o, netwerk i/o, cache i/o (aan zowel server als storage kant), en disk i/o. In performancetests worden daarbij vaak de verkeerde i/o’s getest; veel aangetoonde bottlenecks liggen aan de server- en applicatiekant, maar worden al snel -en onterecht- als tekortkoming van de storage aangemerkt.
In bovenstaande berekeningen is de cache i/o buiten beschouwing gelaten, terwijl die juist zo belangrijk is voor de werkelijke prestaties van de infra; zolang de cache buffer niet volloopt, kun je heel goede performance behalen met zeer weinig disks. Waar je dus naar moet zoeken als je een performancesizing wilt doen, is de echte piekbelasting. Als die hoger is dan de cache kan opvangen, zul je extra spindles moeten inzetten om de data naar disk te kunnen flushen. Maar vaak blijkt dat de cache ruimschoots in staat is de aanvragen op te vangen. Het voordeel voor de klant is een kleinere investering in hardware (en dus ook stroom en koeling).
Het is jammer dat het artikel alleen disk i/o’s betrekt in de performanceberekeningen. Weliswaar leidt dat tot hogere diskverkopen omdat storagemanagers niet graag op te krap bemeten systemen willen werken, maar in de praktijk zijn prestaties van meer variabelen afhankelijk.
Normaal doe ik dit niet, en je zult me een zeur vinden, maar:
Jammer dat het lezen van dit artikel drastisch wordt verstoord door het feit dat iemand die zich Expert noemt het meervoud van Disk niet weet, dat is en blijft toch echt disks, en niet disken. [zie http://woordenlijst.org/zoek/?q=disk&w=w%5D