Database server, raid layout

[voodooless]

Ik heb al heel wat topics doorgewerkt, maar ik hoop dat jullie me nog wat extra tips kunnen geven.

We zijn op zoek naar een nieuwe server voor een van onze databases. Momenteel is deze zo'n 66 GB groot, maar de verwachting is dat dat snel gaat groeien naar meer dan 100 GB. We moeten dus een machine hebben die enige tijd mee kan.

Naast 8 cores (dual quad), en een sloot geheugen (32gb) zal de nieuwe machine ook worden voor zien van de nodige IO infrastructuur. Een flinke array van disks dus.

Gezien de kosten is SSD nog niet interessant, maar wel 15K SAS disks. Deze bieden voor enterprice toepassingen toch wel de meeste io performance.

In onze database zal tamelijk veel geschreven worden, maar ook flink wat gelezen. Hierdoor is random read en write snelheid het meest belangrijke, liefst met zoveel mogelijk processen tegelijk.

Verder zal de gebruikte database Postgresql zijn.

Om het geheel ook nog schaalbaar te houden heb ik het plan gevat om Opelsolaris met ZFS te gebruiken. Dit maakt het schalen naar meer disks lekker makkelijk, en ook de nieuwe IO structuur en ingebouwde raid mogelijkheden zien er erg interessant uit.

Zo hoop ik de optimale balans te vinden tussen hardware en software raid.

Het plan is verder om gewoon een 3U server te nemen en deze gewoon tot de rand te vullen met disks, dus 16 SAS Seagate 15K5 disks. Later kan er altijd nog via FC een extra disk array bij gezet worden, maar ik gok dat dat voorlopig niet nodig zal zijn

Het OS zal op een RAID 1 array van twee disks gezet worden, Dit hoeft niet eens een ZFS pool te zijn. Verder is er nog een postgres transaction log dat zich thuis voelt op losse disks. Ook een RAID1 array, of misschien een raid 10 van 4 disks. Dan blijven er nog 10 of 12 disks over voor de echte database

Raid controller zal een Adaptec ICP 5165BR zijn. Helaas kan ik hier vrijwel geen informatie over vinden , maar met een 8x PCI-e interface zal ie heel wat IO moeten kunnen genereren. Aangezien deze onderdeel is van een forse server gok ik dat ook de firmware goed ik elkaar steekt. Als iemand wat meer info heeft: graag!

Nu heb ik dus verschillende mogelijkheden:

1) HW raid 1 array's maken per twee disks en deze samenvoegen met dynamic striping van ZFS
2) zelfde als 1) maar dan volledig software raid via ZFS mirror en stripe
3) HW raid 10 array van 10 of 12 disks
4) twee RAID5 array maken en deze stripen met ZFS
5) twee raidz(2) arrays maken en deze stripen met ZFS
6) vier kleine raid5 of raidz arrays en deze stripen.
7) een groot raidz(2) array
een groot hardware array

Nu is mijn verwachting dat 1 t/m 3 de beste prestaties zullen leveren, maar je levert hier ook de meeste disk space in. Op zich is dat niet zo erg: disk space zal de komende tijd het probleem niet zijn.

Verder heb ik hier en daar gelezen dat het bij een grote hoeveelheid kwa performance de keuze voor een bepaald raid level niet veel meer uitmaakt. Ik heb echter grote twijfels aan deze uitstraak, en ook een aantal bronnen spreken dit tegen zoals hier: http://blogs.sun.com/roch/date/20060531 . Hier wordt duidelijk dat mirroring toch echt wel de beste random IO performance.

Misschien hebben jullie nog andere ideeën?

[Ankh]

ik zou sowieso aanraden om de 15k schijven van 2.5inch te nemen. Deze zijn iets sneller, wat we op me werk gemerkt hebben. de raid kaart zegt mijn niet zoveel, ben vooral bekend met HP hardware. Maar als hij bbcw (512MB heeft) is het een interessant kaart.

[voodooless]

Ankh schreef op zondag 29 juni 2008 @ 21:52:
ik zou sowieso aanraden om de 15k schijven van 2.5inch te nemen.

We zitten natuurlijk vast aan wat de leverancier ons kan leveren. Maar als het goed is zijn de Cheatah 15K5's 2.5" platters in een normale behuizing Performance is volgens de benchmarks uitstekend. We hebben ze ook in onze kerstverse database server voor onze website zitten, en ook daar doen ze het prima in raid 10:

Version 1.03b       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
jabba           16G 73387  95 151752  28 78147  10 64952  76 259762  17 783.4   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                100 77777  91 +++++ +++ 72288  77 84207  99 +++++ +++ 90689 100

[Verwijderd]

voodooless schreef op zondag 29 juni 2008 @ 22:03:

Maar als het goed is zijn de Cheatah Cheetah 15K5's 2.5" platters in een normale behuizing

[P5ycho]

Ga je ook nog iets doen met ZIL, aka ZFS Intent Log? Hier kun je eventueel een SSD voor gebruiken.
Misschien is het interessant om alles in ZFS af te handelen, bijv. 2x raidz2(6disks) en 2x ssd voor een intent log oid.

Ik denk dat het gewoon even testen wordt wat het beste presteert.

[voodooless]

Dat is inderdaad een goeie! Leuke artikelen over te vinden. Bedankt

[Q]

Ik heb geen professionele ervaring met dit soort opzetten, maar ik vind dit wel interessant.

Als beschikbaarheid belangrijk is dan zou ik zeker 1 of meerdere hot-spares in het cabinet stoppen, zodat je zo kort mogelijk degraded draait. Ik ben zelf nogal paranoide en zou zelfs zo ver willen gaan dat bij uitval van 1 disk er nog niets degraded draait, in die zin dat bij uitval van een 2e disk er iets vreslijks mis gaat.

Gezien het redelijk grote aantal disks is de kans op uitval toch wat groter. Vandaar de hotspare. Eventueel kun je Raid 6 (2 disks mogen uitvallen) kiezen, maar dat zal relatief gezien minder performance geven.

De grote vraag is natuurlijk hoeveel performance voldoende is en in hoeverre beschikbaarheid een issue is. Qua beschikbaarheid is raid 6 + hotspare(s) misschien wel het beste. Het gaat iig efficienter om met je disk capaciteit dan raid 10, maar je levert dus in op performance.

Met dit soort toepassingen zou ik persoonlijk beschikbaarheid op 1 en performance op 2 zetten, maar uiteindelijk hangt dat helemaal af van jouw specifieke omgeving.

Voor een enterprise achtige omgeving zou ik zelf liever voor een volledig op hardware gebaseerde raid kiezen en geen mix maken --> je vergroot de complexiteit maar wat win je er echt mee? Kiss!

Wat opensolaris en zfs betreft: ik zou iets kiezen wat op de eigen omgeving aansluit. Als jullie omgeving veel solaris is, prima, maar is het vooral loenux wat de klok slaat, dan zou ik dat kiezen. Maar dat gaat miscshien te off-topic. ZFS is leuk speelgoed, maar is het mature genoeg? Ik weet het niet.

[ Voor 10% gewijzigd door Q op 30-06-2008 23:48 ]

[voodooless]

Q schreef op maandag 30 juni 2008 @ 23:44:
Ik heb geen professionele ervaring met dit soort opzetten, maar ik vind dit wel interessant.

Wij ook niet, maar als je snel groeit kom je het vanzelf een keer tegen

Beschikbaarheid vs performance verhaal is duidelijk. Performance gaat echter een steeds grotere rol spelen, terwijl de noodzaak voor beschikbaarheid niet zal afnemen. Bij RAID6 of RAIDZ2 win je natuurlijk in beschikbaarheid, maar je levert signifikant in kwa performance. Je zou ook nog kunnen denken aan een array van 3 raid 0 configuraties, die samen een raid 1 vormen. In deze config kunnen er ook (minimaal) 2 disks uitvallen, en met 450 Gb hebben we nog steeds genoeg ruimte. Tevens is er dan plek voor een hor spare en twee SSD's om in RAID 1 de ZIL voor hun rekening te nemen. (Naast twee disks voor OS en twee voor transaction log).

Andere mogelijkheid is een raid 1 van 2 RAID5 of RAIDZ arrays. Dan mogen er ook twee disks uitvallen en heb je ook nog wat extra performance boven een enkele RAID5 implementatie.

Voor een enterprise achtige omgeving zou ik zelf liever voor een volledig op hardware gebaseerde raid kiezen en geen mix maken --> je vergroot de complexiteit maar wat win je er echt mee? Kiss!

In het begin is het misschien wel leuk, maar wat als het niet meer snel genoeg is. Je kunt er dan niet zomaar een stripe bij zetten. Als je ZFS raid gebruikt kan dat dus wel. Alles wordt dynamisch verplaatst om diskruimte zo goed mogelijk te spreiden. Complexiteit valt eigenlijk ook wel reuze mee. ZFS beheertools zijn uitermate simpel en doeltreffend. De vraag is inderdaad wat er te winnen valt. Vermoedelijk zal de IO pipeline van ZFS onder bepaalde omstandigheden beter werken als je hun eigen raid implementatie gebruikt i.p.v het de hardware te laten doen. Hoe dat precies in elkaar steekt zal ik dus moeten uitvinden.

[ Voor 4% gewijzigd door voodooless op 01-07-2008 00:00 ]

[Femme]

Als je overweegt om zestien sas-schijven te gaan gebruiken zou ik toch eens gaan kijken naar solid state disks. Ssd's zoals de Mtron Pro 7000 zijn door hun extreem lage toegangstijd in database-applicaties vele malen sneller dan 15.000 toeren harde schijven. Daardoor ben je met veel minder schijfjes klaar en heb je geen duur extern sas enclosure nodig om je harde schijven in onder te brengen.

Ik heb eerder dit jaar eens gekeken hoe verschillende typen harde schijven en solid state disks presteren op een degelijke raid-adapter (Areca ARC-1680). Daaruit bleek dat de toegangstijd een belangrijke factor is in de performance scaling van de raid-configuratie. Een trage harde schijf komt maar heel moeizaam aan het prestatieniveau van een snellere harde schijf of solid state disk.

Het volgende grafiekje zegt genoeg:



Ik heb ook wel configuraties getest met zestien 10.000 toeren schijven en veertien 15K schijven. De solid state disks zijn met vier stuks al sneller.

[voodooless]

Femme schreef op dinsdag 01 juli 2008 @ 00:00:
Als je overweegt om zestien sas-schijven te gaan gebruiken zou ik toch eens gaan kijken naar solid state disks. Ssd's zoals de Mtron Pro 7000 zijn door hun extreem lage toegangstijd in database-applicaties vele malen sneller dan 15.000 toeren harde schijven. Daardoor ben je met veel minder schijfjes klaar en heb je geen duur extern sas enclosure nodig om je harde schijven in onder te brengen.

Gelukkig past alles in een 3U kast SSD's zijn inderdaad een leuk alternatief als de prijs past. Bij onze leverancier zijn 16 15K5 SAS disks 1000 euro goedkoper dan 4 64 GB SSD disks. En met 4 disks (en dus 128GB in RAID10, of 192 Gb in RAID5) komen we helaas niet ver genoeg. Voorlopig wel, maar straks niet meer. We kunnen er natuurlijk wel mee beginnen en later meer toevoegen natuurlijk.

Op zich zijn de extra centen niet zo erg natuurlijk, maar om voldoende storage te hebben moeten we gewoon meer SSD's hebben. Ik zal morgen onze leverancier eens vragen of er ook grotere SSD's zijn (weet ook nog steeds het exacte type niet ).

[ Voor 5% gewijzigd door voodooless op 01-07-2008 00:15 ]

[Emmeau]

raid5 wordt alom afgewezen voor een database met veel updates.
RAID 0+1 is wat dat betreft een betere oplossing.

Is verder een hoop over te vinden op het net.

maar zoals altijd geld er: meten is weten.

Bij een traject van deze grootte zou ik zeker ruime tijd inruimen voor het benchmarken van de nieuwe machine. Alleen dan zal je echt weten (en kunnen aantonen) wat de beste oplossing is voor deze specifieke situatie.

[voodooless]

Emmeau schreef op dinsdag 01 juli 2008 @ 00:22:
maar zoals altijd geld er: meten is weten.

Natuurlijk! Je gaat echter niet zomaar een server kopen met een berg SSD's om er vervolgens achter te komen dat je met een berg SAS'jes beter uit geweest was (of andersom)

Zijn dus toch echt dingen die je op het "droge" zult moeten uitvinden.

[Q]

voodooless schreef op maandag 30 juni 2008 @ 23:57:
[...]


Wij ook niet, maar als je snel groeit kom je het vanzelf een keer tegen

Beschikbaarheid vs performance verhaal is duidelijk. Performance gaat echter een steeds grotere rol spelen, terwijl de noodzaak voor beschikbaarheid niet zal afnemen. Bij RAID6 of RAIDZ2 win je natuurlijk in beschikbaarheid, maar je levert signifikant in kwa performance. Je zou ook nog kunnen denken aan een array van 3 raid 0 configuraties, die samen een raid 1 vormen. In deze config kunnen er ook (minimaal) 2 disks uitvallen, en met 450 Gb hebben we nog steeds genoeg ruimte. Tevens is er dan plek voor een hor spare en twee SSD's om in RAID 1 de ZIL voor hun rekening te nemen. (Naast twee disks voor OS en twee voor transaction log).

Andere mogelijkheid is een raid 1 van 2 RAID5 of RAIDZ arrays. Dan mogen er ook twee disks uitvallen en heb je ook nog wat extra performance boven een enkele RAID5 implementatie.

Helder verhaal.

Raid 1 kost je relatief veel opslagruimte, daar zou ik zelf niet snel voor kiezen, behalve dan als boot ofzo. Met 16 disks (-2 voor boot) -> 14 disks heb je volgens mij een relatief vlotte Raid 6 array maar ik heb alleen geen idee hoe zoiets qua IO doet tov Raid 10. Je merkt, ik ben gek op raid 6, maar dat zal niet voor iedereen de oplossing zijn. Ik lees hierboven al dat raid 5 (en dus raid 6) bij veel schrijf-transacties niet aan te raden is.

In het begin is het misschien wel leuk, maar wat als het niet meer snel genoeg is. Je kunt er dan niet zomaar een stripe bij zetten. Als je ZFS raid gebruikt kan dat dus wel. Alles wordt dynamisch verplaatst om diskruimte zo goed mogelijk te spreiden. Complexiteit valt eigenlijk ook wel reuze mee. ZFS beheertools zijn uitermate simpel en doeltreffend. De vraag is inderdaad wat er te winnen valt. Vermoedelijk zal de IO pipeline van ZFS onder bepaalde omstandigheden beter werken als je hun eigen raid implementatie gebruikt i.p.v het de hardware te laten doen. Hoe dat precies in elkaar steekt zal ik dus moeten uitvinden.

Tegen die tijd dat je 16 disks niet meer genoeg storage bieden denk ik dat het systeem mogelijk al aan vervanging toe is, als ik dit zo lees. Als je nu al verwacht weldegelijk over die capaciteit te gaan, dan zou je ook een SAN oplossing kunnen overwegen. Dan ben je helemaal flexibel. De san-omgeving kun je ook weer delen met andere systemen en services. Maar of dat rendabel is, is natuurlijk de vraag.

Je storage van je db server scheiden lijkt mij eigenlijk geen heel slecht idee. De DB server hoeft zich minder met disk-zooi bezig te houden. Maar SAN met FC en knappe redundancie is duur. Alles heeft zijn voor en nadelen.

Verder zou je kunnen denken aan nog meer RAM in het ding te gooien. Ik gok dat dit nog de meeste prestatie winst geeft. En dan hoeft je disk subsystem niet extreem snel te zijn, waardoor je wat meer op zeker kan spelen in je raidconfig. Maar het is maar waar je prioriteit ligt.

[voodooless]

Q schreef op dinsdag 01 juli 2008 @ 00:26:
Raid 1 kost je relatief veel opslagruimte, daar zou ik zelf niet snel voor kiezen, behalve dan als boot ofzo. Met 16 disks (-2 voor boot) -> 14 disks heb je volgens mij een relatief vlotte Raid 6 array maar ik heb alleen geen idee hoe zoiets qua IO doet tov Raid 10. Je merkt, ik ben gek op raid 6, maar dat zal niet voor iedereen de oplossing zijn. Ik lees hierboven al dat raid 5 (en dus raid 6) bij veel schrijf-transacties niet aan te raden is.

Probleem met RAID 5 of 6 array's is dat het lezen relatief veel sneller gaat dat het schrijven, in een db met veel inserts kan dat zeker nadeling zijn. Aangezien disk space niet echt een issue is met 150 GB disks, is raid 10 of een variant eigenlijk helemaal niet zo erg.

Tegen die tijd dat je 16 disks niet meer genoeg storage bieden denk ik dat het systeem mogelijk al aan vervanging toe is, als ik dit zo lees. Als je nu al verwacht weldegelijk over die capaciteit te gaan, dan zou je ook een SAN oplossing kunnen overwegen. Dan ben je helemaal flexibel. De san-omgeving kun je ook weer delen met andere systemen en services. Maar of dat rendabel is, is natuurlijk de vraag.

Ik hoop eigenlijk dat we voorlopig ingedekt zijn kwa performance. Daarom dat er nu ook goed over nagedacht moet worden. Willen we nog meer, kunnen wel altijd nog een SAN via FC aansluiten natuurlijk.

Je storage van je db server scheiden lijkt mij eigenlijk geen heel slecht idee. De DB server hoeft zich minder met disk-zooi bezig te houden. Maar SAN met FC en knappe redundancie is duur. Alles heeft zijn voor en nadelen.

Tja, met de huidige servers met 8 cores en mooie controllers is het bezighouden met diskzooi niet meer zo kritisch als vroeger natuurlijk. Bovendien is een losse SAN een grofweg dubbel zo grote investering.

Verder zou je kunnen denken aan nog meer RAM in het ding te gooien. Ik gok dat dit nog de meeste prestatie winst geeft. En dan hoeft je disk subsystem niet extreem snel te zijn, waardoor je wat meer op zeker kan spelen in je raidconfig. Maar het is maar waar je prioriteit ligt.

De aangeboden servers slikken maximaal 32 GB. wil je meer kom je op een hogere range server uit, en daar kunnen niet zoveel disks in en zit je sowiso vast aan een SAN. Al met al dus een vele malen duurdere oplossing. Bovendien is meer memory sowiso al uitstel van executie. Als de DB groeit gaat ie toch wel een keer niet meer in RAM passen en zit je toch weer met je disks opgescheept.

[Verwijderd]

Realiseer je wel dat 2-phase writes bij RAID5 lang niet zo ernstig zijn bij SSDs als bij mechanische disks, omdat er praktisch geen zoektijd is, en de meeste I/O voor 2-phase write zijn READS! En dat doen flash disks met superveel IOps, ook al is de I/O niet sequentiëel zoals bij RAID5 writes.

[voodooless]

Dat ben ik me inderdaad aan het realiseren

Komt nog eens bij dat de aangeboden SSD's (Supertalent DuraDrive AT) militair grade zijn met een MTBF van meer dan een miljoen uur en een endurance spec van 350 jaar bij 50GB schrijf/wis per dag. Dat zijn erg nette cijfers

Vreemd is alleen dat burst speed van de SSD niet beter is dan normale sequentiële reads. Blijkbaar zit er geen cache in de SSD.

Lijkt er dus op dat het inderdaad die kant op zal gaan. 2 normale disks voor het OS, en dan 4 SSD's in RAID5 voor de database. Gezien het aantal IOPS zal het vermoedelijk ook geen probleem zijn om het transaction log en de ZIL op deze zelfde array te houden, of denken jullie daar anders over?

[ Voor 12% gewijzigd door voodooless op 01-07-2008 22:12 ]

[Emmeau]

transaction log en DB zou ik altijd gescheiden houden, en liefst zelfs op een andere controller.

Mocht je raid controller met je database om wat voor reden dan ook de geest geven, dan kan je met een backup + transaction log terug naar (crash - 1ms).
(crasht je schijvenset me je transactie log, tijd voor een DB backup natuurlijk)

Daarnaast is het je controller dubbel belasten bij updates, indien je transactionlogs naar dezelfde disk gaan.

Altijd blijven kijken of je single point of failures kunt vermijden. Raid5 is leuk als je disk stuk gaat, maar als met 1 controller blijft het een SPOF.

[voodooless]

Tja, als ik daar ook nog losse SSD's voor moet nemen en ook nog een nieuwe controller, reizen de kosten toch wel fink de pan uit vrees ik. Misschien is het wel mogelijk om de disks voor het los op de SATA controller van het moederbord te plaatsen. Het is sowiso zonde om voor die twee disks weer een peperdure RAID controller te nemen.

Verder kun je je afvragen hoe snel zo'n controller kapot gaat. Ik verwacht niet dat dat sneller gebeurt dan bijvoorbeeld het moederbord zelfs. In dat geval is de extra veiligheid van een nieuwe controller een illusie. Blijf je nog met de extra belasting zitten door er nog wat schijfjes aan te hangen. Hoe groot is dat probleem? Ik mag toch wel verwachten dat de huidige controllers er toch best wel mee overweg zullen moeten kunnen... Controller zal waarschijnlijk ICP 5085BL zijn met 800 Mhz CPU of de ICP 5165BR met zelfde CPU (voor zover ik dat heb kunnen achterhalen).

[ Voor 4% gewijzigd door voodooless op 02-07-2008 09:55 ]

[Emmeau]

Dan zou ik zeker voor de transaction log voor schijven op een (interne) sata controller gaan.

Tuurlijk, de kans dat je Adaptec controller de geest geeft is miniem. Maar mocht het gebeuren, dan ben je wel het bokje. Ik herinner me bij een klant, waarbij een raid array de geest gaf op een machine omdat een batterijtje op de controller leeg was (en een dag later ging de schaduw machine onderuit om dezelfde reden).
Kortom, er kan van alles fout gaan, waardoor er een corruptie plaats vindt op een opslagmedium.

Transaction log is een schitterend systeem om je database te repareren, zorg dan ook dat het bruikbaar is, op de manier waarop het bedoeld is?

Ik zou zelf, voordat ik ook maar SSD schijven of wat dan ook koop eerst eens gaan meten op je huidige server, en kentallen gaan bepalen.
Ooit een benchmark traject gedaan op een VAX-VMS machine (Oracle database geloof ik) en daar konden we gewoon met getallen aantonen dat er een dermate hoge i/o load was, dat in 4 jaar een bepaald batch proces 4 dagen zou gaan duren, terwijl een aantal beheerders die niet gemeten hadden een bloedsnelle machine wilde hebben, omdat het wel 'leuk' was, en dachten dat het probleem dan wel opgelost zou zijn.

Maar je redo-logs zou ik zeker op andere disks zetten dan de datafiles. sata-2 in raid-0 functioneert ook best aardig en haalt een hoge i/o.

Vooralsnog valt er verder weinig te zeggen zonder kentallen.

[Q]

Over kentallen gesproken: aan wat voor soort belasting zit je te denken? Heb je een idee welke performance vereist is in termen van bijv. transacties per seconde oid?

[voodooless]

Emmeau schreef op woensdag 02 juli 2008 @ 12:24:
Ik zou zelf, voordat ik ook maar SSD schijven of wat dan ook koop eerst eens gaan meten op je huidige server, en kentallen gaan bepalen.

Dat is dus het probleem: dat is weinig zinvol omdat er structureel nogal wat dingen gaan veranderen. We weten dus niet wat er precies uit gaat komen. Daarom zullen we moeten kijken naar een zo optimaal mogelijk oplossing. En als we dan 4K extra moeten uitgeven om ook in de toekomst vooruit te kunnen, dan moet dat maar...

Ik kan dus momenteel weinig anders zeggen over transactions per seconde, behalve de getallen die ik al eerder aangaf in een ander topic: grofweg 1000K inserts per dag. Dat is wat er nu zo'n beetje gebeurt. Het kan makkelijk zo zijn dat over een jaar deze getallen minimaal verdubbelen (de hoop is dat het nog veel meer gaat worden). Daarnaast zullen er nog een flink aantal read request gedaan worden, veelal simpele opvragingen van id tot id met een simpel filter van meerdere duizend rows.

Natuurlijk is het vervelend dat de server crashed, en je je data kwijt bent. Natuurlijk is er nog altijd een backup van de vorige dag die je kan terugzetten. Dat geeft je wat boze klanten, maar kan verder weinig kwaad. Aan de andere kant is het natuurlijk prettig als het zaakje wat betreft betrouwbaarheid nog wat beter in elkaar steekt, zeker als het niet veel kost.

Maar je redo-logs zou ik zeker op andere disks zetten dan de datafiles. sata-2 in raid-0 functioneert ook best aardig en haalt een hoge i/o.

RAID 0 kan makkelijk kapot, lijkt me dus niet zo handig...

[ Voor 17% gewijzigd door voodooless op 02-07-2008 21:17 ]

[voodooless]

Even een update, want vandaag is de knoop doorgehakt. Aangezien de benchmarks van de SSD die onze leverancier kan leveren zwaar tegenvielen (en zij leverden ook zelf de benchmark resultaten;) ), en er geen andere SSD leverbaar zijn de komende tijd (vast wel ergens anders, maar als ik het SSD topic lees dan zie ik daar ook steeds meer ellende voorbij komen), is besloten om de server gewoon met SAS disks uit te voeren. dual quad core xeons@2.6, 64 GB memory en 16x147GB 15K.5 SAS op een ICP 5165BR controller moeten het paard voorlopig gaan trekken Als meer IO nodig is kan er altijd nog een FC kaart in en een los chassis met nog meer disks

Hoe de indeling gaat zijn staat nog open en zal bepaald worden aan de hand van uitgebreide testen in verschillende configuraties.

Ik zal eens kijken of ik tzt hier wat resultaten neer kan gooien Minimaal twee weken wachten..

[_Arthur]

voodooless schreef op donderdag 07 augustus 2008 @ 22:52:
ICP 5165BR controller

Ding heeft ondertussen een bijna antieke IOP onboard. Lijkt me erg zonde van die vele disks en de eventuele performance.

[voodooless]

_Arthur schreef op vrijdag 08 augustus 2008 @ 22:45:
Ding heeft ondertussen een bijna antieke IOP onboard. Lijkt me erg zonde van die vele disks en de eventuele performance.

Ondertussen is de server binnen en ik kan inderdaad bovenstaande bevestigen. Wat ik ook doe, veel meer dan 350 MB/sec krijg ik niet uit de controller geperst (of erin), zelfs niet met een raid 10 array van 14 disks... Zelfde geld voor de schaalbaarheid van random write iops.

Heb de leverancier gevraagd voor een andere controller... hier hebben we natuurlijk niets aan... Heb je 16 snelle disk, kun je ze niet vol belasten

Adaptec RAID 51645 any good

[_Arthur]

voodooless schreef op donderdag 21 augustus 2008 @ 10:07:
Ondertussen is de server binnen en ik kan inderdaad bovenstaande bevestigen. Wat ik ook doe, veel meer dan 350 MB/sec krijg ik niet uit de controller geperst (of erin), zelfs niet met een raid 10 array van 14 disks... Zelfde geld voor de schaalbaarheid van random write iops.

Dat had ik je dus al verspelt

(Heb zelf een controller met de 333 iop gehad met 8 disks en toen was de controller al een bottleneck).

Heb de leverancier gevraagd voor een andere controller... hier hebben we natuurlijk niets aan... Heb je 16 snelle disk, kun je ze niet vol belasten

Adaptec RAID 51645 any good

Die ziet er al beter uit. Maar anders zoek eens rond op het grote intahweb of je benchmarks van die kaart kan vinden.

[voodooless]

_Arthur schreef op donderdag 21 augustus 2008 @ 10:41:
Die ziet er al beter uit. Maar anders zoek eens rond op het grote intahweb of je benchmarks van die kaart kan vinden.

Helaas niet, alleen wat Adaptec zelf gebenched heeft (op een niet iets andere kaart van de zelfde serie)... En dat ziet er goed uit. Bottlenek zit daar op 800 MB/sec zo te zien, wat meer is dat de andere testkandidaten (Wat natuurlijk te verwachten is als Adaptec zelf testen doet) .Daarnaast zit ik natuurlijk nog met de leverbaarheid vanuit onze leverancier.

[ Voor 32% gewijzigd door voodooless op 21-08-2008 16:25 ]

[Verwijderd]

Wat heb je aan die MB/s terwijl je het juist van IOps moet hebben, neem ik aan. Tijdens realistisch gebruik, en zeker bij een database server, zul je weinig grote/contiguous reads/writes hebben. Gelukkig zijn 15K SAS disks prima voor IOps, maar legt het daarbij wel af tegen een goede SSD. Je zei dat de benchmarks tegenvielen die je leverancier je gaf, mag ik die eens zien? Ben wel benieuwd.

Als het goed is haal je bij een SSD ongeveer 30.000 IOps per disk voor leesacties, tegenover 120 bij een 7200rpm STA disk, zeg 200 voor een 15k rpm disk. Gelukkig is database-toegang niet zo erg als pure random I/O: de request size is hoger en ook niet puur random maar redelijk dicht bij elkaar in de buurt. Bovendien zijn veel SSD's slecht met random write; maar een nieuwe Intel SSD die binnenkort uitkomt zou zo'n 4.000 IOps random write halen, dat is zeker geen slechte score. Ik heb wel een paar vragen:

• Hoe groot is je database, past die niet in RAM?
• Hoeveel reads heb je ten opzichte van writes, in percentage?

[ Voor 10% gewijzigd door Verwijderd op 21-08-2008 15:34 ]

[CodeCaster]

Verwijderd schreef op donderdag 21 augustus 2008 @ 15:32:

• Hoe groot is je database, past die niet in RAM?

voodooless schreef op zondag 29 juni 2008 @ 21:41:
Momenteel is deze [database] zo'n 66 GB groot, maar de verwachting is dat dat snel gaat groeien naar meer dan 100 GB.

voodooless schreef op dinsdag 01 juli 2008 @ 00:36:
De aangeboden servers slikken maximaal 32 GB. wil je meer kom je op een hogere range server uit, en daar kunnen niet zoveel disks in en zit je sowiso vast aan een SAN.

[voodooless]

Verwijderd schreef op donderdag 21 augustus 2008 @ 15:32:
Wat heb je aan die MB/s terwijl je het juist van IOps moet hebben, neem ik aan. Tijdens realistisch gebruik, en zeker bij een database server, zul je weinig grote/contiguous reads/writes hebben. Gelukkig zijn 15K SAS disks prima voor IOps, maar legt het daarbij wel af tegen een goede SSD. Je zei dat de benchmarks tegenvielen die je leverancier je gaf, mag ik die eens zien? Ben wel benieuwd.

Benches kan ik je helaas niet geven, maar het viel echt heel erg ruim tegen met de SSDs die men ons kon leveren. Sowieso zijn SSD voorlopig niet niet aan de orde, met name vanwege de beschikbaarheid, en toch nog aanhoudende problemen met interfaces en diverse combinaties van controllers, en natuurlijk de random write performance. SSD's die wel goed presteren zijn relatief gezien gewoon vreselijk duur. We zien over een jaar wel weer...

Aan MB/sec hebben we niet veel, maar zegt wel wat over de bandbreedte van de controller. Duidelijk was ook te zien dat het aantal IOPS niet goed schaalde met het aantal disks. 4 disk raid 10 was niet significant slechter 8 disk raid 10. Hier zou je grofweg een verdubbeling verwachten, en dat was het bij lange na niet. Drama was helemaal compleet als je van twee arrays ging lezen (van zelfde controller).

CodeCaster schreef op donderdag 21 augustus 2008 @ 15:41:

Machine heeft toch 64 GB memory gekregen Anyway, we weten nog niet hoe groot de nieuwe database gaat worden om dat er structureel een aantal dingen anders zijn geworden. 'T hoeft ook niet allemaal in memory te passen natuurlijk, daarvoor hebben we dus snelle disk IO nodig Een upgrade naar 128 GB memory zou de server ook een factor 3 duurder maken

[Verwijderd]

Let erop dat je RAM vooral actieve data zal cachen; zo is je database misschien 100GB maar wordt er bijvoorbeeld slechts 54GB actief gebruikt. Als je in elk geval je actieve dataset in RAM kunt houden, hoef je je alleen nog maar zorgen te maken over de writes en kun je veel druk van de ketel houden voor je disk array.

Om welk merk/type SSD's ging het trouwens?

[voodooless]

Verwijderd schreef op donderdag 21 augustus 2008 @ 17:43:
Let erop dat je RAM vooral actieve data zal cachen; zo is je database misschien 100GB maar wordt er bijvoorbeeld slechts 54GB actief gebruikt. Als je in elk geval je actieve dataset in RAM kunt houden, hoef je je alleen nog maar zorgen te maken over de writes en kun je veel druk van de ketel houden voor je disk array.

Dat is ook precies de bedoeling, vandaar ook dat verschillende tabellen gepartitioneerd worden. Het zal niet in all gevallen 100% passen, maar dat is niet erg.

Om welk merk/type SSD's ging het trouwens?

Supertalent DuraDrive AT series.

[P5ycho]

Misschiein een stomme vraag, maar waarom zit je zo vast aan die ene leverancier? Kun je niet gewoon wat beter spul ergens anders vandaan slepen? We weten allemaal dat een stel mtrons of seagate 15k's met een areca controller zo ongeveer het beste is wat je kunt implementeren, toch?

[_Arthur]

P5ycho schreef op vrijdag 22 augustus 2008 @ 09:13:
Misschiein een stomme vraag, maar waarom zit je zo vast aan die ene leverancier? Kun je niet gewoon wat beter spul ergens anders vandaan slepen? We weten allemaal dat een stel mtrons of seagate 15k's met een areca controller zo ongeveer het beste is wat je kunt implementeren, toch?

Sommige bedrijven willen dat hardware vaak voor langere tijd ondersteunt wordt dmv carepacks e.d. Met een eigen knutselconfig is dat heel erg vaak toch niet mogelijk.

[voodooless]

P5ycho schreef op vrijdag 22 augustus 2008 @ 09:13:
Misschiein een stomme vraag, maar waarom zit je zo vast aan die ene leverancier? Kun je niet gewoon wat beter spul ergens anders vandaan slepen? We weten allemaal dat een stel mtrons of seagate 15k's met een areca controller zo ongeveer het beste is wat je kunt implementeren, toch?

Andere leverancier betekend waarschijnlijk een server die fix duurder is. Wat betreft Areca: daar is onze leverancier vanaf gestapt vanwege stabiliteitsproblemen met linux. Bovendien spant Areca niet meer de performance kroon als ik Toms Hardware mag geloven. De nieuwe generatie Adaptec controllers doen het uitzonderlijk goed. Kans is groot dat onze leverancier eentje uit deze serie zal kunnen leveren. Vanmiddag hoor ik meer.

En natuurlijk gaan wij hier ook niet zelf effe snel een server in elkaar hacken uit was losse onderdelen in de hoop dat het geheel wel een beetje stabiel kan zijn. Voor dit soort toepassingen kun je je het gewoon niet veroorloven als het niet lekker loopt, en als er iets kapot is moet het ook snel gefixed kunnen worden.

[ Voor 15% gewijzigd door voodooless op 22-08-2008 11:06 ]

[P5ycho]

Natuurlijk snap ik je motivatie om alle hardware bij dezelfde leveancier te betrekken, ik vind het alleen raar dat ze je dan zo'n oude raid adapter meegeven. Betrouwbaar, ok, maar zo kun je over een jaar weer bij ze aankloppen. Niet voor de betrouwbaarheid maar voor de snelheid. Heb je net zo veel downtime met een beetje pech.
Ik hoop dat die nieuwe adaptecs, waar ik nog niets over gelezen heb overigens, een beetje beter presteren

[voodooless]

In ieder geval heeft de leverancier bevestigd dat er saturatie plaatsvind met zoveel disks. Ze gaan nog wat dingen benchen de komende dagen, en dan horen we meer, maar wat mij betreft gaat er gewoon een nieuwe Adaptec in

[voodooless]

Zo, volgens de leverancier zou een upgrade naar een nieuwere adaptec niet veel uitmaken (en we zouden er ook nog zelf voor moeten betalen)...

Heb zelf ook weer liggen benchen om de benches te kunnen vergelijken die ze zelf op een vergelijkbaar systeem hebben gedaan. Ik heb zelfs remote toegang gekregen tot hun testsysteem zodat ik daar zelf e.a. kon doen. Probleem is dat de excel sheets die ik van hun heb gekregen niet rijmen met wat ik zelf op hun machine bench; zelfde instellingen, zelfde bench. Wat ik wel zie is dat de resultaten die ik eruit krijg vergelijkbaar zijn met die van ons eigen systeem.

Hier de benches die ik heb gedaan op ons eigen systeem met iometer:


Alle tests zijn gedaan met 50 workers. Ik denk dat het beeld wel duidelijk is, alles behalve random write schaalt totaal niet. Het maakt voor de performance weinig uit of ik nu een 6 disk raid 5 array maak, of een 12 disk raid 10 array

Nog een detail: de controller had niet de laatste firmware versie, die ik heb ik dus geupgrade naar de nieuwste versie. Ging allemaal prima. Als ik nu echter in de controller bios een array wil aanmaken van een disk blijft de software hangen op het array configuratie scherm. Als ik dan meerder schijven kies gaat het wel verder, maar waar ik het array type kan selecteren staan er bij bepaalde keuzeopties een berg vreemde tekens... Ik heb zo'n donkerbruin vermoeden dat dat niet in orde is... Oude versie maar weer terug gezet, want die heeft hier geen last van.

Mijn vraag aan de leverancier was dan ook: waarom hebben wij nu 16 schijven gekocht als we met 6 stuks de zelfde performance hadden kunnen halen

[Verwijderd]

voodooless: gebruik je partities op de array? Het valt me op dat 2MB stripe een significante invloed heeft. Of gaat het om filesystem blocksize? Als het wel de stripesize is, vermoed ik dat je een filesystem misalignment hebt. Een grotere stripesize betekent dat je procentueel minder last hebt van een misalignment maar het probleem verdwijnt er niet helemaal door.

[voodooless]

Geen partities, die 2MB is niet de stripe size, maar de blokgrootte die de benchmark gebruikt. De stripesize heb ik gezet op 256KB.

[Femme]

voodooless schreef op vrijdag 22 augustus 2008 @ 10:51:
[...]

Andere leverancier betekend waarschijnlijk een server die fix duurder is. Wat betreft Areca: daar is onze leverancier vanaf gestapt vanwege stabiliteitsproblemen met linux. Bovendien spant Areca niet meer de performance kroon als ik Toms Hardware mag geloven. De nieuwe generatie Adaptec controllers doen het uitzonderlijk goed. Kans is groot dat onze leverancier eentje uit deze serie zal kunnen leveren. Vanmiddag hoor ik meer.

De storage benchmarks van Tom's Hardware zijn erg crappy, daar zou ik niet veel waarde aan hechten. Het klopt wel dat Adaptec de laatste jaren heeft gewerkt aan verbetering van cachingalgoritmen. De nieuwe modellen met de 1,2GHz IOP348 zouden erg goed moeten schalen. Een voordeel van Adaptec is tevens de zeer gelikte managementsoftware. Areca heeft dit minder goed in orde.

[voodooless]

Zojuist heb ik eindelijk remote kunnen testen met de Adaptec RAID 51645, met 10 disk Raid 10.

Resultaat is dat deze controller met name met kleine blocksizes veel sneller is, in bepaalde gevallen grofweg factor 10

Random read met 128K bloksize doet ongeveer 178 MB/sec t.o.v 17 MB/sec op de ICP.
Mix van 75% read, 50% random doet ook ongeveer 170 MB/sec t.o.v 21 MB/sec op de ICP.

De kaart krijgen we binnen 3 dagen binnen, en dan kunnen we hier eindelijk aan de slag met een degelijke controller

[Q]

Dus het vermoeden dat de controller de boosdoener was is hiermee redelijk bevestigd. Ben benieuwd hoe het afloopt.

[voodooless]

Q schreef op maandag 29 september 2008 @ 20:39:
Dus het vermoeden dat de controller de boosdoener was is hiermee redelijk bevestigd. Ben benieuwd hoe het afloopt.

Ik ook! Ik hoop ook dat deze nog leuk gaat doen met OpenSolaris zodat we ook nog een beetje met ZFS kunnen spelen. Maar goed, over 3 dagen weet ik meer...

[voodooless]

Kaart is eergisteren binnen gekomen en ik heb inderdaad een aantal dingen kunnen testen. Eerste indruk is dat deze kaart absoluut sneller is dan de oude!

Natuurlijk heb ik ook lekker gespeeld met ZFS en diverse configuraties om vast te stellen wat nu de beste config is. Uiteindelijk heb ik naast twee disks in controller raid 1 voor het OS gekozen voor het aanmaken van 4 raid 0 configs van 3 disks. Deze heb met ZFS gecombineerd tot twee mirrors die samen weer een stripe vormen. Ik heb ook getest met een volledige zfs software raid oplossing, dit zorgt echter voor een behoorlijk hoge CPU load, en aangezien alle 16 disks door het OS individueel aangesproken worden zorgt dit ook voor en behoorlijke IO load richting controller. Dit kan deze wel aan, maar de nu gekozen opstelling lijkt toch beter uit te pakken. Dan blijven er nog twee disks over. Deze heb ik ingesteld als een mirror en zij vormen het ZFS intent log (ZIL), en helpen om random writes te sequentialiseren. Hot spares zijn er niet. Ik kan altijd het ZIL uitzetten en een van deze disks als spare gebruiken. De controller heeft verder nog 4 externe kanalen. Hier zouden ooit nog wel eens wat snelle SSD's aan gehangen kunnen worden in RAID0. In ZFS kun je deze devices als snelle 3rd level cache gebruiken. Dit heeft echter vooral nut voor het lezen van data, en veel minder voor het schrijven. Voorlopig niet aan de orde dus.

Komende week real life testen met PostgreSQL + PostGIS

[voodooless]

Zo, even een kleine update met wat praktijk testen

Met een flinke select waarvoor heel wat IO gebruikt moet worden ("select count(*) from tabel" met een miljard rows) haal ik zo'n 12K (met uitschieters naar boven en beneden) (min of meer) random IOPS met 8K request size. Dat is zo'n 1000 IOPS per disk, en volgens bij is dat best behoorlijk lijkt me zo. Onze oude server met 4 disk in raid 10 haalt hier beduidend minder. 600 IOPS kreeg je daar niet uit geperst. Prima vooruitgang dus.

Het is nu nog een kwestie van ZFS ARC cache en de PostgreSQL buffers zo instellen dat performance optimaal is voor onze applicatie.

En dan rest het voor de toekomst alleen nog maar om te wachten op betrouwbare SSD's die ook goede performance leveren en niet te duur zijn

[Q]

Die 600 iops was dat ook per disk? die 12000 random iops zijn denk ik prima. Anyway, leuk om de afloop te horen.

[voodooless]

Q schreef op donderdag 30 oktober 2008 @ 23:11:
Die 600 iops was dat ook per disk?

Nee, dat is voor de totale array

[voodooless]

Teleurstelling alom

OpenSolaris blijkt erg instabiel, zodanig dat deze niet meer wil booten, en de install CD werkt ook niet meer

Dan toch maar weer op linux teruggrijpen... We zijn nu diverse distro's aan het testen, met vooralsnog waanzinnig teleurstellende resultaten. Zowel random als sequential read en write laten voor een simpele mirror t.o.v een 12 disk raid10 of raid50 exact de zelfde belabberde resultaten zien. Lijkt erop dat Adaptec hun linux drivers totaal verneukt heeft...

[ Voor 4% gewijzigd door voodooless op 06-11-2008 17:58 ]

[Q]

En FreeBSD, is dat nog een optie gezien de hardware?

[_Arthur]

voodooless schreef op donderdag 06 november 2008 @ 17:57:
Lijkt erop dat Adaptec hun linux drivers totaal verneukt heeft...

Volgens mij is dat nooit anders geweest met Adaptec en linux/unix smaakjes.

[voodooless]

_Arthur schreef op zaterdag 08 november 2008 @ 15:08:
Volgens mij is dat nooit anders geweest met Adaptec en linux/unix smaakjes.

Het "leuke" was dat onze leverancier juist vertelde dat ze geen Areca meer voeren omdat Linux support zo bagger was

Ondertussen heb ik al Ubuntu 8.04, 8.10, CentOS5 (met Adaptec drivers) en Gentoo met laatste kernel getest. Ook heb ik firmware van de Adaptec geüpdate naar de laatste versie. Volgens adaptec was dat nodig omdat hun firmware en drivers de zelfde versie zouden moeten hebben omdat peformance anders niet goed zou zijn. Lulkoek natuurlijk, want het maakt helemaal geen bal uit.

Q schreef op zaterdag 08 november 2008 @ 14:29:
En FreeBSD, is dat nog een optie gezien de hardware?

Die staat als volgende op het menu... Ook nog een SLES10 eval, omdat Adaptec die officieel support, maar helaas hebben de luitjes van Suse hun website verneukt waardoor de ISO's niet te downloaden zijn

[_Arthur]

voodooless schreef op maandag 10 november 2008 @ 10:30:
Die staat als volgende op het menu... Ook nog een SLES10 eval, omdat Adaptec die officieel support, maar helaas hebben de luitjes van Suse hun website verneukt waardoor de ISO's niet te downloaden zijn

Hier kan je SLES10 SP2 ook als eval downloaden (moet je alleen wel weer een accountje bouwen): http://www.novell.com/products/server/eval.html

[voodooless]

_Arthur schreef op maandag 10 november 2008 @ 11:22:
Hier kan je SLES10 SP2 ook als eval downloaden (moet je alleen wel weer een accountje bouwen): http://www.novell.com/products/server/eval.html

Precies dat hebben ze dus gesloopt Account heb ik, ook eval code, alleen de download links werken niet.

Edit: bij nader inzien lag het aan onze proxy server.

Er staat nu freebsd op de machine... nu alleen nog iometer gecompileerd krijgen... zucht

Edit: en dat laatste gaat dus niet lukken zonder zelf de hele meuk zelf te porteren

En nog maar een edit:

Heb zojuist Windows Enterprise 2008 64-bit erop gezet. En dit laat wel de gewenste resultaten zien 760 MB/sec sequential read, en zo'n 16 MB/sec random read. Write resultaten zijn van vergelijkbare aard. Mooi dus. Probleem is alleen: wij willen geen Windows gebruiken

Ik kan dus alleen maar concluderen dat de linux drivers gewoon ronduit slecht zijn De bal ligt nu weer bij Adaptec. Ik heb ze uitgebreide info gegeven over het probleem. Als ze zich er nu nog onderuit willen maken gaat de kaart (alweer) terug naar de leverancier.

Als het dan zover gaat komen rest nog de vraag: welke 16 poort SAS controller zou een alternatief kunnen zijn... ARC-1680x-16 comes to mind als linux peformance wel goed is..

[ Voor 50% gewijzigd door voodooless op 10-11-2008 16:53 ]

[voodooless]

Right... nu komt Adaptec aanzetten met het smoesje dat de arrays gequickinit zijn, en dus niet gerebuild/verified. Dat zou kwa performance veel uitmaken. Dat is waar voor raid5, maar voor raid10 is dat echt niet nodig. Wat dat er dan mee te maken heeft dat dit alleen voor linux geldt weet ik ook niet...

Maar goed, als Adaptec het wil testen we dat toch...

... wat denk je: maakt op Linux 0,0 verschil: precies de zelfde bagger performance. Duh

Natuurlijk wist ik dat van te voren al. Nu maar weer afwachten wat ze nu weer gaan zeggen. Als het antwoord niet naar tevredenheid is gaat de kaart echt terug.

[ Voor 11% gewijzigd door voodooless op 11-11-2008 12:37 ]

[Femme]

voodooless schreef op maandag 10 november 2008 @ 11:26:
[...]

Als het dan zover gaat komen rest nog de vraag: welke 16 poort SAS controller zou een alternatief kunnen zijn... ARC-1680x-16 comes to mind als linux peformance wel goed is..

Volgens mij zijn de ervaringen met Areca's onder Linux toch gewoon goed? De prestaties zullen waarschijnlijk ook beter zijn.

[voodooless]

Femme schreef op dinsdag 11 november 2008 @ 12:46:
Volgens mij zijn de ervaringen met Areca's onder Linux toch gewoon goed? De prestaties zullen waarschijnlijk ook beter zijn.

Dat weet ik dus niet. Heb nog niet echt concreet niets gezien en zoals ik al eerder zei was onze leverancier juist van Areca afgestapt vanwege de Linux problemen Maar goed, of ik dat nu nog als geloofwaardig moet beschouwen weet ik ondertussen ook niet meer....

[analog_]

Ik gebruik thuis een Areca 1130 (oud dingetje) en op het werk een 8 ports pci-x en 16 ports pci-e van areca. (geen exacte nummers nu). Allemaal op debian en het werkt prima. Ze draaien nu al meer dan een jaar als samba doos.

[voodooless]

Mr.SiS schreef op dinsdag 11 november 2008 @ 16:33:
Allemaal op debian en het werkt prima.

Wat is prima? Die Adaptec werkt ook prima, performance is alleen brak

[analog_]

voodooless schreef op dinsdag 11 november 2008 @ 19:17:
[...]
Wat is prima? Die Adaptec werkt ook prima, performance is alleen brak

Ik doelde op de 'brakke' linux driver support van areca. Performance is allemaal prima zover ik heb getest met de arecas.

[voodooless]

'T wordt met de dag mooier bij Adaptec.

Nu gaan ze Linux zelf de schuld geven dan de problemen, en ik moet maar gaan aankloppen bij de support van de distro's... Omdat ze die niet supporten.

Mooi, dan laat ik toch SLES erop staan, wat ze wel supporten... Maar natuurlijk hoor je daar weer helemaal niets over

Ik ben het langzaam echt zat met die gasten daar...

Edit: Ik heb ook nog even een mailtje gestuurd naar Areca om te vragen of ze me konden helpen aan linux benchmarks... Helaas hadden ze daar niet erg trek in Misschien had ik naar de sales afdeling moeten mailen

Nu heb ik weer FreeBSD op de bak staan. IOmeter doet het hier niet, maar we kunnen wel zien dat postgresql vele malen sneller is dan op Linux en zelfs sneller dan OpenSolaris. Enige puntje is dat wel al een corrupte database hadden terwijl we aan het restoren waren Ik hoop dat dat eraan lag dat we daarnaast nog wat enge dingen met de database aan het doen waren... Voorlopig ziet de tweede poging er in ieder geval nog goed uit.

[ Voor 46% gewijzigd door voodooless op 14-11-2008 17:28 ]

[Q]

Zeg, iets heel anders: als je het geklooi nog niet zat bent ben ik persoonlijk heel benieuwd hoe plain old Linux software raid (mdadm etc) performed qua io in jouw omgeving. Dan profiteer je niet zo van de raid kaart zelf en het belast je systeem meer, maar een 8 core 32 GB ram host kan wel wat hebben lijkt mij dan. Ik vraag me af of het relatief tov een hardware kaart echt zo heel slecht presteert qua io.

[voodooless]

Ik denk eigenlijk dat met dermate disks, je wel degelijk een nadeel gaat krijgen met je IO. Als je even zoekt naar een PDF'je van Intel over de SCSI layer in de Linux kernel, zul je zien dat je daar relatief veel tijd verliest. Doe je dat maal 12, dan kun je je indenken dat IO performance wel eens niet zo geweldig zou kunnen zijn. Ik heb er ook nog aan gedacht om dat te testen, maar helaas moet de machine in de lucht in zodat mensen erop kunnen ontwikkelen. Een andere aanwijzing was de load die de Solaris machine genereerde als je ZFS het volledige disk arsenaal laat besturen. Dat was ten eerste niet sneller dan een combinatie tussen hardware en software, en ten tweede was de load op de CPU's (alle dermate hoog dat er voor de database nog maar weinig overblijft. Nu heeft FreeBSD ook weer zfs, alleen als ik daar de known issues lees, dan weet ik nu al dat ik dat niet ga proberen

En helaas heb je met een database van 100 en 250 GB niet even zo een reserve machine staan om tijdelijk op te werken Gelukkig is gisteren de tweede restore actie gelukt, en heeft de database nu het hele weekend de tijd om te converteren.

[ Voor 3% gewijzigd door voodooless op 15-11-2008 09:32 ]

[Q]

Ok, helder verhaal. Dus je draait nu FreeBSD + native UFS filesystem en postgres? Grappig dat je daar (noodgedwongen) op uit komt en dat het nog goed lijkt te perforrmen ook. Ook al werkt iometer niet, wat queries in postgres zou wel een aardige indicatie moeten kunnen geven, als je een referentie hebt (met oude server bijv).

Oh, draai je nu gewoon hardware RAID x op die machine met werkende drivers?

[ Voor 10% gewijzigd door Q op 17-11-2008 01:58 ]

[voodooless]

Dat is inderdaad wat we gedaan hebben. Hey omzetten dan de ene database naar de andere is een mooie performancemeter. Straks eens kijken wat de uitkomst is

We draaien nu inderdaad RAID6 met 12 disks, en een RAID 1 voor het transaction log. Lijkt een prima combinatie.

[_JGC_]

Wat betreft linuxsupport ben ik erg tevreden over 3Ware. Zolang je die dingen uitrust met een BBU en dus de write cache aan kunt zetten zijn het goede controllers onder linux zonder problemen. We hebben hier 3Ware controllers van de 8000 serie, de 9000 serie, de 9550SXU, de 9690SA en de 9650SE. Performance is goed, vooral op de 9690SA in combinatie met een 6-tal 15K RPM SAS disks in RAID-10.
Helaas heeft 3Ware alleen nog maar de 9690SA op het gebied van SAS, en die is alleen te krijgen met 2, 4 of 8 poorten.

[voodooless]

Het Adaptec feest gaat door.

Hun laatste statement is dat ik disk write cache maar aan zou moeten zetten (wat ik dus niet wil) Ik zou maar een BBU en UPS moeten gebruiken (Uiteraard hebben we beiden).. Dat is ook geen verklaring voor snelheidsverschillen tussen de OS'en.

Verder blijven ze volhouden dat verschillen in de OS'en ervoor zorgen dat de verschillen zo groot zijn... Ik heb hem maar gevraagd of dat een officieel Adaptec standpunt is... Het kan echt niet zo zijn dat er verschillen van factor 12 zijn, dat is echt onzin.

Nu maar weer wachten op het volgende zinloze antwoord

[_JGC_]

Writeback cache op je disks aanzetten om het feit dat je controller geen fatsoenlijke writeback cache onboard heeft te verdoezelen? Dat zou ik ook niet accepteren.

[P5ycho]

Als daptec nu eens ervoor ging zitten om je verder te helpen, maar als ik je zo hoor lopen ze alleen maar te zeiken en jou af te schilderen als incompetent. Lekkere lui.

[voodooless]

Ik denk (weet zeker) eerder dat die support gast incompetent is . Hij leest klaarblijkelijk posts niet goed, gaat niet in op serieuze vragen, en blijft zichzelf maar herhalen.

Rede genoeg om hem nu te dwingen om een echt statement te maken waar ik straks iets mee kan.

[Q]

voodooless schreef op maandag 17 november 2008 @ 07:54:
Dat is inderdaad wat we gedaan hebben. Hey omzetten dan de ene database naar de andere is een mooie performancemeter. Straks eens kijken wat de uitkomst is

We draaien nu inderdaad RAID6 met 12 disks, en een RAID 1 voor het transaction log. Lijkt een prima combinatie.

Mijn inschatting ook, voor wat die waard is.

De vraag is nu of FreeBSD een acceptabel en robuust platform is om mee verder te gaan, of slechts tijdelijk om verder te kunnen.

Gezien de perikelen met Adaptec, is het misschien wijsheid om gewoon die kaart te retourneren + geld terug en een ander merk/type te gaan regelen? Makkelijk praten, maar het is waarschijnlijk wel de beste oplossing. Zelfs als hierdoor extra kosten worden gemaakt denk ik dan. Welke kaar je dan zou moeten najagen, geen flauw idee. Areca is hier bij tweakers populair maar hoe doen die kaarten het onder Loenux?

[voodooless]

Q schreef op donderdag 20 november 2008 @ 21:06:
De vraag is nu of FreeBSD een acceptabel en robuust platform is om mee verder te gaan, of slechts tijdelijk om verder te kunnen.

Op het enen probleem met de corrupte database hebben we tot nu toe weinig problemen gehad. Dennog willen we niet op FreeBSD blijven werken.

Feit blijft echter dat OpenSolaris met ZFS nog steeds veruit de snelste setup was, en ook stabiel, in ieder geval zolang je niet ging rebooten Ik hoop dat de nieuwe release snel uit kom, dan gaan we dat snel weer proberen.

Voorlopig is het nog geen productie machine, dus we kunnen nog wel het een en ander testen, echter moet de database ook gebruikt kunnen worden om applicaties te testen. Beiden samen doen kan helaas niet

Gezien de perikelen met Adaptec, is het misschien wijsheid om gewoon die kaart te retourneren + geld terug en een ander merk/type te gaan regelen? Makkelijk praten, maar het is waarschijnlijk wel de beste oplossing. Zelfs als hierdoor extra kosten worden gemaakt denk ik dan. Welke kaar je dan zou moeten najagen, geen flauw idee. Areca is hier bij tweakers populair maar hoe doen die kaarten het onder Loenux?

Dat laatste is nu juist precies het punt, dat weet ik niet, en Areca was ook niet van plan om mij daar enige informatie over te verstrekken. Vreemde verkooppraat daar

Edit: heb net een mailtje gedaan naar [e-mail]. Ik hoop dat ik daar wat intelligentere antwoorden ga krijgen.

[ Voor 4% gewijzigd door voodooless op 21-11-2008 10:59 ]

[voodooless]

En alweer krijg ik een uitwijkend antwoord van Adaptec.. Ze hebben in het support archive niet kunnen zien dat ik vanalles getest heb, en of ik dat archive op zou willen sturen...

Nou... eigenlijk niet. Ik weet namelijk het antwoord wat dan gaat komen al, en dat brengt me geen stap verder tot de oplossing.

op de mail naar aacraid heb ik nog geen antwoord. Ik hoop dat ik daar nog wat op ga ontvangen. Verder heb ik ook nog maar een keer bij onze leverancier het probleem neergelegd.