Areca ARC-1220, combineren van SSD en HDD in RAID10?

[bartvb]

Ik heb een database server waarvan de database in de loop der jaren flink gegroeid is, we zitten nu op zo'n 110GB. Server is wat RAM betreft ook wat meegegroeid (van 8GB naar 24GB) maar op dit moment begint de database server weer de grote bottleneck te worden in het geheel:



Het systeem heeft een Areca ARC-1220 met BBU en 4x500GB 7200 samen met 4x 74GB Raptor (eigenlijk 3x + 1x 160GB ivm vervangen van defecte raptor). Database staat natuurlijk op de raptors.

Het idee is nu om te kijken of SSD lucht kan geven, grote probleem zijn de random reads en SSD zou daar erg sterk in moeten zijn. Nadeel van SSD is dat de (niet enterprise grade) SSDs wat minder betrouwbaar zijn, na een flink aantal writes zijn ze gewoon op en waarschijnlijk gaan twee dezelfde SSDs ook op ongeveer hetzelfde moment 'stuk'.

Mooiste zou zijn als ik nu twee raptors zou kunnen vervangen door twee SSDs waarbij het geheel in RAID10 draait. Grote vraag is alleen wat de Areca daarvan gaat vinden. Mijn vermoeden is dat de Areca alles 100% gelijkmatig verdeelt over de disks in een raidset waardoor de performance verbetering maximaal 50% is tov de Raptors.

Ideaal zou zijn als de Areca de SSDs zou gebruiken voor al het leeswerk en de Raptors eigenljik alleen gebruikt als (net iets achterlopende) mirror. Iemand een idee hoe deze RAID controller omgaat met raidsets die bestaan uit sterk afwijkende disks?

Zijn er andere mogelijkheden om deze combinatie te realiseren? Enige waar ik op kom is het maken van een RAID1 van 2 SSDs met 2 Raptors als hotspare maar ook dat kost 50% performance.

[Cereal]

Ik verwacht dat je óf geen performancewinst hebt, of een onvoorspelbare/variabele prestatie.
Een mirror moet altijd gesynced zijn, anders mis je het voordeel van Raid1, je wilt absoluut geen filecorruptie omdat je Raptors nét niet gesynced waren toen er een SSD failde..

Is het geen idee om 2 Raid 1 arrays aan te maken, 1 van 2x SSD en 1 van 2x raptor, en de SSD's of Rapors te gebruiken voor de de transaction logs.
Ik heb even niet paraat welk onderdeel van de database juist schrijf/lees/response snelheid nodig heeft, dus dit moet je nog wel even uitzoeken. Maar wellicht iets om uit te zoeken/te overwegen.

[redfoxert]

Als de database dermate bedrijfskritisch is en de performance is merkbaar achteruit aan het gaan, waarom dan niet investeren in fatsoenlijke SSD's?

Persoonlijk zou ik geen SSDs met HDDs gaan mixen in een dergelijke omgeving.

Als test zou je een aantal goedkopere SSDs kunnen aanschaffen om te zien of de performance daadwerkelijk verbetert alvorens je gaat kijken naar Enterprise SSDs. Die "consumenten" SSDs kan je daarna vast ook wel ergens anders in kwijt

[bartvb]

Raid moet idd altijd in sync zijn, maar dat is iets dat de write buffer van de Areca op kan vangen, zeker door de aanwezigheid van die batterij. Schrijven naar de DB is niet het grootste probleem (en schrijven is waar die logs om de hoek komen kijken). Het probleem is vooral dat er regelmatig data opgehaald wordt die verspreid is over de volledige DB. Heel erg veel random reads dus wat de SSDs erg snel moeten kunnen doen. Waar ik echter bang voor ben is dat er 2 reads naar de SSDs gaan en 2 reads naar de Raptors waarna de SSDs staan te wachten tot zij weer aan de beurt zijn.

Vraag me af of de Areca slim genoeg is om te zien dat die SSDs al lang klaar zijn met de leesopdracht en dus ook meteen weer een nieuwe opdracht kunnen krijgen.

[ Voor 3% gewijzigd door bartvb op 28-10-2010 10:22 ]

[bartvb]

@redfoxert: Allereerst is het budget gewoon niet toereikend voor 4 enterprise SSDs. 4 Intel X25-Es van 64GB komen al op 2000 euro. Voor dat geld kan je een hoop andere leuke dingen doen. Verder is het zo dat als er een SSD dood gaat dat geen probleem is zolang een andere disk of ander systeem het maar opvangt. Performance nu (zonder SSD) is nog behoorlijk acceptabel.

Enterprise spul is leuk als het niet je eigen geld is dat je uitgeeft en je management hebt dat boos wordt als er door uitval een paar procent performance verlies is. In mijn geval zijn de overwegingen net wat anders Ik bespaar graag een paar duizend euro voor een oplossing die prima werkbaar is maar waar idd iets meer kans is op uitval.

[ Voor 9% gewijzigd door bartvb op 28-10-2010 10:34 ]

[redfoxert]

Aangezien ik niet weet waar de database voor gebruikt word e.d. lijkt me dat je dan met 4 gewone SSDs uit de consumenten lijn ook prima uit de voeten kan. 4x 60-80G zit je dan op 400-500 euro

De vraag is dan, hoe snel gaan die SSDs naar de eeuwige jachtvelden? Volgens mij valt het tegenwoordig best mee gezien de wearleveling capaciteiten van de firmwares, alsook het extra geheugen dat op de SSD zit voor spare geheugencellen.

[leonbong]

Je kan ook seagates moments XT overwegen.
Dit zijn 7200 notebookschijven die sneller zijn dan bijna elke normale 7200 schijf. Deze schijven gebruiken een 4gb SLC cache op de schijf zelf. Voor lees acties die veel over dezelfde sectoren heb je dan feitelijk een SSD.

Of een paar normale SSD en zfs als filesystem nemen dan kan je een cache deel defineren (lees SSD raid set) en normaal deel gewone schijven dus.

[ Voor 21% gewijzigd door leonbong op 28-10-2010 11:47 ]

[redfoxert]

leonbong schreef op donderdag 28 oktober 2010 @ 11:45:
Je kan ook seagates moments XT overwegen.
Dit zijn 7200 notebookschijven die sneller zijn dan bijna elke normale 7200 schijf. Deze schijven gebruiken een 4gb SLC cache op de schijf zelf. Voor lees acties die veel over dezelfde sectoren heb je dan feitelijk een SSD.

Met een database van 110G heb je daar dus helemaal niks aan. Die Momentus XT's zijn, met name, interessant voor laptops zodat de veel gevraagde files (meestal OS bestanden) in de 4G cache komen te staan en de laptop met opstarten sneller word.

[TERW_DAN]

bartvb schreef op donderdag 28 oktober 2010 @ 10:21:


Vraag me af of de Areca slim genoeg is om te zien dat die SSDs al lang klaar zijn met de leesopdracht en dus ook meteen weer een nieuwe opdracht kunnen krijgen.

Nope, dat doen ze niet. Als je die dingen gaat mixen in een array wacht de controller tot de traagste disk klaar is. Ik heb zelf een keerjte op mijn 1220 een vrij gare combinatie gedraaid van 7 750GB SATA schijven en 1 aanzienlijk tragere 750GB PATA schijf via een Abit Serillel (zodat ik iig kon rebuilden tot de schijf terug was van RMA). En dat gaf al behoorlijk wat performanceloss, doordat 1 schijf gewoon stukken trager is.

[m_w_mol]

Als je die dingen gaat mixen in een array wacht de controller tot de traagste disk klaar is.

Een waarheid als een koe. Nooit, maar dan ook nooit, mixen in RAID-configuraties in productie-omgevingen. Bij voorkeur allemaal dezelfde harddisks (zelfde merk, type, grootte en zelfs firmware).

[ Voor 24% gewijzigd door m_w_mol op 28-10-2010 12:03 ]

[TERW_DAN]

m_w_mol schreef op donderdag 28 oktober 2010 @ 12:01:
[...]


Een waarheid als een koe. Nooit, maar dan ook nooit, mixen in RAID-configuraties in productie-omgevingen. Bij voorkeur allemaal dezelfde harddisks (zelfde merk, type, grootte en zelfs firmware).

Je kunt nog beter 8 iets kleinere schijven (bijvoorbeeld 160 of 250GB Enterprise harddisks) in RAID6 aan je RAID-controller hangen, dan mixen van merken, typen, of -- in dit geval -- technologieën.

Je kunt prima mixen hoor, alleen zal het wellicht niet de snelste methode zijn.

Ik heb nog tijden lang gewerkt met die config tot m'n schijf terug was en dat ging ook gewoon goed, het is alleen niet het snelste

[ItsValium]

Ik zou toch opteren om meteen een viertal x25m's of soortgelijk te gebruiken en niet je array te mixen tussen ssd en hdd. Voor de prijs van vier x25m's 80 gb moet je het niet laten en monitor het aantal writes op de schijven dmv monitor software. Eénmaal de writes het max aantal writes opgegeven door fabrikant benaderd of net overschrijd, onmiddellijk vervangen. Zo kan je tegen beperkte kost toch genieten van het gigantische voordeel die ssd's bieden in db storage.

[leonbong]

redfoxert schreef op donderdag 28 oktober 2010 @ 11:48:
[...]


Met een database van 110G heb je daar dus helemaal niks aan. Die Momentus XT's zijn, met name, interessant voor laptops zodat de veel gevraagde files (meestal OS bestanden) in de 4G cache komen te staan en de laptop met opstarten sneller word.

Het is nooit dat hele database altijd alle sectoren de meest gevraagde zijn. Dus met 4 schijven heb je effectief een 16GB lees/schrijf chache en dat scheelt, bij het schrijven van toegangslogs. Opvragen van data zal ongeveer gelijk zijn aan de snelheid van 7200 toeren schijven.

[redfoxert]

leonbong schreef op donderdag 28 oktober 2010 @ 13:13:
[...]

Het is nooit dat hele database altijd alle sectoren de meest gevraagde zijn. Dus met 4 schijven heb je effectief een 16GB lees/schrijf chache en dat scheelt. Bij het schrijven van toegangslogs opvragen van data zal ongeveer gelijk zijn aan de snelheid van 7200 toeren schijven.

Zal best maar je kan alleen nooit snelheid garanderen aangezien je niet kan aanwijzen welke blokken naar de cache moeten. Die 16GB is ook nog eens als je alleen maar RAID0 gebruikt, omdat dan elk blok per disk uniek is. Bij RAID10 heb je ineens nog maar 8GB effectief waarvan ook nog eens blocks dubbel in de cache kunnen voorkomen.

Nee, de Momentus XT lijkt mij in dit geval zeker geen oplossing

[voodooless]

Ik zou no way standaard consumer SSD's gebruiken voor database werk, whatever de workload... Minimaal Intel X25-E of beter (SLC of enterprise grade MLC flash). Performance is eigenlijk minder belangrijk dan betrouwbaarheid in dit geval. De performance boost heb je toch wel, en die zal je flink merken (beetje afhankelijk van de workload).

Wij lopen momenteel zelf ook tegen een dergelijke grens aan. We zitten nu met zo'n 400GB aan data, en dat zal naar verwachting groeien naar enkele TB's over een paar jaar. SSD's zijn dan gewoon te kostbaar. Ik heb nu een controller en los disk cabinet besteld met plek voor ruim 40 disks. Een deel (6 stuks) daarvan gaat op aan SSD's (Intel X25-E). Dit gaat in RAID0 als cache dienen. De rest wordt deels gevuld met 15k SAS disks. Deze vormen enkele raid6 (raidz2 eigenlijk) array's, die weer gestriped worden. Aangezien de actieve data maar een relatief klein stuk van de database omvat zal de cache behoorlijk effectief zijn. Schijf performance is veel minder een probleem en de SAS disks kunnen dat prima af.

En wat als een van de cache disks kapot gaat: maakt niet uit, OS detecteert dat en gebruikt de defecte disk niet meer. Dataverlies treedt hier niet bij op, alleen een tijdelijke performance drop.

En ga je toch aan de gang met SSD's, ga dan liever voor wat meer disks en zet ze in RAID6 of RAID10DM. Dat komt de betrouwbaarheid zeer zeker ten goede. Merk wel op dat aangezien de write belasting op alle disks in een array vrijwel gelijk is. De kans dat ze allemaal rond de zelfde tijd defect gaan is behoorlijk groot.

Owja: RAM, RAM, RAM

[ Voor 11% gewijzigd door voodooless op 28-10-2010 21:54 ]

[Femme]

Ik heb wel eens verschillende typen harde schijven in raid getest op een Areca. De prestaties kwamen dan te liggen in het midden van beide harde schijven als deze in een uniforme raidset gebruikt zouden worden. Bij database I/O mag je aannemen dat de meeste I/O's zo klein zijn dat ze binnen een enkele stripe vallen. Er wordt dan maar één van de drives in de raidset aan het werk gezet om die I/O te verwerken. De prestatiewinst zit 'm in het feit dat je meerdere I/O's tegelijkertijd kunt verwerken. Bij kleine I/O's zullen de prestaties soms van ssd-niveau zijn en soms van harddiskniveau. Bij sequentiële I/O vormen de Raptors de bottleneck, echter is de hoge toegangstijd van een harde schijf dan een minder grote issue.

In theorie zou het dus wat moeten helpen.

[DJ-Visto]

Ik weet een heel snel o.s, kan je cache disks aantoevoegen alles, het is ZFS en het is Nexentastor/ met een goed vooruitzicht. o.s gratis versie is tot 12TB ruw (dus 12x1TB nog niks in RAID etc). (je kan ook eens op kijken op zfsbuild. Voor een beetje inspiratie.)

[ Voor 0% gewijzigd door DJ-Visto op 28-10-2010 23:44 . Reden: Hmm, een link niet goed gedaan + haakjes niet gesloten, foei ]

[voodooless]

Neem dan gewoon Nexenta. Dan heb je geen last van de 12TB grens. Voor een database heb je de -stor versie niet echt nodig.

[DJ-Visto]

voodooless schreef op vrijdag 29 oktober 2010 @ 06:59:
Neem dan gewoon Nexenta. Dan heb je geen last van de 12TB grens. Voor een database heb je de -stor versie niet echt nodig.

Kan best, ik wist als enige deze, en die paar keer dat hij hier getest is beviel het prima.

[ Voor 24% gewijzigd door DJ-Visto op 29-10-2010 07:34 ]

[bartvb]

voodooless schreef op donderdag 28 oktober 2010 @ 21:51:
Ik zou no way standaard consumer SSD's gebruiken voor database werk, whatever de workload... Minimaal Intel X25-E of beter (SLC of enterprise grade MLC flash). Performance is eigenlijk minder belangrijk dan betrouwbaarheid in dit geval.

[...]

Owja: RAM, RAM, RAM

Voor die betrouwbaarheid heb je slaves en RAID De kans dat de SSDs allemaal binnen een week of 2 dood gaan lijkt me vrij klein. Eventueel zou ik zelfs een slave op dezelfde machine kunnen laten draaien die zijn database op de RAID5 met 4x500GB heeft staan. Op die manier is er helemaal geen downtime als alle SSDs spontaan uit de lucht gaan op hetzelfde moment. Wat InnoDB row operations betreft kom ik op 75k reads/sec en 30 writes. Read:Write ratio van 2500:1 dus Het gaat hier overigens om de database server voor het forum van www.bokt.nl

RAM is idd erg belangrijk maar heb al 24GB in die machine zitten, alle slots zitten vol zou dus 4x2GB moeten vervangen door 4x4GB. Voor die upgrade koop ik ook 4 (niet enterprise) SSDs en met die RAM upgrade staat nog steeds niet de hele DB in RAM.

Maar iedereen dank voor de input! Mixen van SSD en Raptors in een RAID10 lijkt geen handige optie. ZFS met SSD als cache is leuk maar lijkt geen heel betrouwbare optie onder Linux en niet handig om alleen daarvoor over te stappen op Solaris

Ik kom dus uit op 4 betaalbare SSDs (X25-M, Vertex 2) in RAID 10. Enterprise SSDs zijn leuk maar de features heb ik niet nodig (en worden niet gebruikt door de Areca), de betrouwbaarheid is prettig maar zijn de extra kosten niet waard en de extra snelheid is tov harddisks maar relatief.

Iedereen super bedankt voor de input iig! Als ik het niet vergeet post ik hier nog een update met de voor/na resultaten. Er is maar weinig info te vinden over de real-life impact van overstappen op SSD bij databases.

[_Arthur]

bartvb schreef op vrijdag 29 oktober 2010 @ 12:22:
Er is maar weinig info te vinden over de real-life impact van overstappen op SSD bij databases.

Aangezien je write:read verhouding ga je daar weinig problemen mee hebben. Reads zijn niet levensduur-verkortend voor een SSD. Waarbij writes dat wel zijn.

[voodooless]

Neem er liever 5 of 6 SSD's in RAID6. Dan ben je wat betreft betrouwbaarheid een stap verder, en performance zal niet veel slechter zijn, of zelfs beter in sommige gevallen. Extra prijs is relatief weinig.

[bartvb]

Heb alleen geen plek voor 6 SSDs Controller heeft 8 poorten en daarvan zijn er al 4 in gebruik door de RAID5 met 4 HDDs. Met 4 disks is RAID6 ook te doen (en wat capaciteit betreft gelijk aan RAID10) maar je levert 50% performance in bij writes:

http://www.xbitlabs.com/a...reca-arc1220_3.html#sect1

[DJ-Visto]

bartvb schreef op zaterdag 30 oktober 2010 @ 10:43:
Heb alleen geen plek voor 6 SSDs Controller heeft 8 poorten en daarvan zijn er al 4 in gebruik door de RAID5 met 4 HDDs. Met 4 disks is RAID6 ook te doen (en wat capaciteit betreft gelijk aan RAID10) maar je levert 50% performance in bij writes:

http://www.xbitlabs.com/a...reca-arc1220_3.html#sect1

Je hebt ook sas expanders maar zo te horen heb jij een sata areca.

[_Arthur]

bartvb schreef op zaterdag 30 oktober 2010 @ 10:43:
Heb alleen geen plek voor 6 SSDs Controller heeft 8 poorten en daarvan zijn er al 4 in gebruik door de RAID5 met 4 HDDs. Met 4 disks is RAID6 ook te doen (en wat capaciteit betreft gelijk aan RAID10) maar je levert 50% performance in bij writes:

http://www.xbitlabs.com/a...reca-arc1220_3.html#sect1

Opties genoeg natuurlijk waarbij je eerst een 4 disk Raid6 aanmaakt, je data verhuist van de Raid5 naar de Raid6 array. Daarna de Raid5-disks vervangen en je Raid6 array online expanden.

Als je de Raid5 set als 'backup' wilt behouden kan je volgens mij inderdaad het beste naar een Raid10 array toegaan met, bijvoorbeeld, 4x de Intel X25M 160GBers.

[voodooless]

bartvb schreef op zaterdag 30 oktober 2010 @ 10:43:
maar je levert 50% performance in bij writes:

Je eigen quote:

Wat InnoDB row operations betreft kom ik op 75k reads/sec en 30 writes. Read:Write ratio van 2500:1 dus

Dus wat is belangrijk?

[bartvb]

Goed punt.

Ik heb echter niet het idee dat die SSDs allemaal binnen een paar weken defect gaan, op zich voldoende tijd om te vervangen voor de verkeerde twee disks gelijktijdig offline gaan. Daarnaast zijn er backups en is er een slave DB server. Betrouwbaarheid is belangrijk (want scheelt een hoop gedoe) maar niet heel kritisch.

RAID6 met 4 disks zou ik wel doen als het snelheidsverschil relatief klein zou zijn (20% ofzo). Write speed is tijdens gemiddeld gebruik niet zo heel boeiend aangezien de load nogal read-heavy is. Tijdens een 'ALTER TABLE' of het importeren van data krijg je echter een heel ander plaatje.

Areca is idd een SATA uitvoering, daarnaast heeft de kast maximaal plaats voor 8 disks Die 4x500GB zijn idd op dit moment nog nodig, misschien op termijn die taken (backups 's nachts) verplaatsen naar een andere machine en dan nog 2 SSDs bijprikken.

[bartvb]

Zaterdag nacht heb ik de 4x WD Raptor 74GB in RAID 10 vervangen door 4x OCZ Vertex 2 120GB en het resultaat mag er zijn. Vervangen is tot nu toe nog niet meer geweest dan het een voor een uit de kast trekken van de disks en vervangen door een SSD (bij de eerste SSD duurde dat 1:50, laatste SSD was in 12 minuten klaar ).

Hier het voor/na plaatje:



Rond 00:30 was het vervangen van de disks klaar, een erg duidelijk verschil in iowait dus. Aantal slow queries (2 seconde) is ook gedaald. Tot nu toe erg goede upgrade.

Nu de array nog een keer opnieuw aanmaken (zodat de volle 120GB gebruikt kan worden) en die gelegenheid ook aangrijpen om ibdata1 flink kleiner te maken, we gebruiken al een hele tijd 1 tablespace per tabel, ibdata1 is daardoor onnodig groot.

Ander dat uitgezocht moet worden is dat de array niet boven de 3000 IOPs uit lijkt te komen (volgens iostat). Geen idee waar dat aan ligt, indeling van de array? Beperking van de Areca?

[ Voor 12% gewijzigd door bartvb op 22-11-2010 09:36 ]