Diskperformance optimaliseren onder budget

[Ethirty]

Ik ben momenteel bezig met de analyse van een file server met slechte disk-performance. Ik weet dat het mis is, het is ook merkbaar en meetbaar, maar ik probeer het te quantificeren voor het management.

Het gaat om een Windows Storage Server met zo'n 5TB aan data, verdeeld over 3 SATA arrays, een 8 disk R6 array en 2x 4 disk R5 arrays. Alle disks zijn verdeeld over 2 cabinets aan 2 verschillende controllers. Dit is historisch zo gegroeid en de bron van de bottleneck. De server die dit alles aanstuurt begint oud te worden en loopt ook vaak te pieken in CPU, dus die moet ook vervangen worden.

De data bestaat uit zeer veel kleine en middelgrote files (ik schat >>1mln per array, niet fatsoenlijk te bepalen). Er wordt veel geschreven, dus meer IOPS en meer controller cache zullen een positief effect hebben. De aanvoer van data gaat over maximaal een 100Mb WAN connectie (wel 24/7), dus het is wel duidelijk dat het disk-systeem de bottleneck is. Het systeem staat eigenlijk alleen maar op zichzelf te wachten tot het een keer allemaal instort.

De constante cijfers uit Perfmon tijdens een korte meting spreken eigenlijk al boekdelen:
% disktime > 300% (50% limiet)
Average disk read queue ~2 (<2 limiet)
Average disk write queue >5 (<2 limiet)
Split I/O >100 (duidt oa op hoge fragmentatie wat klopt, >500k fragments in een file is geen uitzondering)

Het liefst adviseer ik in dit geval gewoon veel 2.5" SAS 15k Enterprise disks, maar daarvoor is geen geld. Het zal dus SATA moeten blijven. Wellicht zit er nog SAS Midline (7.2k) in, als de performance/aantal/prijs ratio beter uitvalt dan voor SATA. Ook wil ik proberen zo veel mogelijk van de bestaande investeringen te handhaven. Op de nominatie voor hergebruik staan in ieder geval de HP P600 controller (3G SAS, 1.5G SATA) en een MSA60 LFF behuizing en een aantal 3.5" 750GB SATA disks.

De gedachte is om met het berekende aantal disks te bepalen of controller en behuizing genoeg zijn en, zo niet, wat daar dan nog extra bij komt (MSA60 is te stacken op de P600). Met die disks maak ik dan 1 grote R6 array met meerdere logische disks (elk ~2TB). Het alternatief is meerdere R5 arrays en 1 of 2 hotspares, maar met de omvang en verwachtte groei voelt R6 veiliger. Uiteraard zal ik deze keer wel rekening houden met de stripesize, blocksize en partitie-alignment.

De data is cruciaal en kan slechts zeer beperkt offline, dus een inplace upgrade is noodzakelijk. Door de slechte performance is even een backup maken lastig geworden, de window is te kort en de data te dynamisch. Ik wilde dan ook de MSA60 afvullen met disks, evt een 2e MSA60 erbij als dit nodig is voor het aantal spindles. Dan de data verhuizen van de oude arrays naar de nieuwe en dan de cabinet(s) en controller omzetten naar een nieuwe server. Dit geeft me volgens mij het meest stabiele en betrouwbare upgrade pad.

Ik kan meten hoeveel performance er precies nodig is door de rest van de counters te analyseren (er staan nog 2 24-uurs metingen gepland, tellers voor cpu, mem, physical en logical disk), maar waar ik tegen aanloop is om dat om te zetten in aantallen disks. Ik kan wel een nummer pakken (bijv 200 IOPS voor de SAS en 100 voor de SATA), maar hoe reëel is dat? En hoe ga je van huidige IO niveau + queues, niet genoeg dus, naar het gewenste niveau met extra marge?

Ik heb geprobeerd IOPS-info over de disks te vinden op de site van HP of te herleiden met de info die ze wel hadden, maar daar kom ik maar niet uit. Ik heb ook geen mogelijkheden om dit zelf te meten met verschillende disks, dus ik moet ergens uit gaan van gegeven of geschatte waardes. Zonder deze getallen kan ik dus eigenlijk niks met mijn gemeten/te meten data en kan ik geen vergelijking maken tussen de kosten voor een SATA danwel SAS oplossing. Elk artikel op internet dat ik kan vinden gaat voornamelijk over het bepalen van het aantal benodigde IOPS, maar geen enkele over het aantal beschikbare. Whitepapers van HP over hun SATA en SAS drives levert eigenlijk ook niks op. Er wordt wel geschreven dat IOPS belangrijk zijn, maar er wordt niets gekwantificeerd voor de verschillende soorten drives.

Het enige dat ik na lang zoeken vind is een formule op een random site:
diskIOPS = 1 / ((1 / (diskRPM/60) /2) + diskSeekLatency/1000)
Hiermee kom ik voor HP-disks uit op 79 voor SATA en 182 voor 15k SAS.

---

Zojuist de eerste cijfers van een deelmeting van 14 uur door Excel gehaald, maar ik denk dat het ergens flink mis gaat.

	% CPU time	Curr.Disk queue	Disk sec/transfer (ms)	Disk sec/read (ms)	Disk sec/write (ms)
Min	0,06	0	1,87	0	2,43
Max	1E+15	102	203,09	87,11	300,14
Avg	2,99E+14	9,85	40,40	18	75,04
Grens	< 80	< 2	< 20	< 20	< 20

Uitschieters zoals bij de CPU max zitten bijna in elke kolom zoals in de disk read/write queue (8E+16) en de Split I/O (1E+17). Disk read/sec en write/sec zit ook ergens rond de 1E+17 dus het lijkt er een beetje op dat óf ergens gaat iets helemaal mis met puntjes en komma's óf de server is zodanig overbelast dat meten geen reële cijfers meer oplevert.

Als ik wat formules gebruik van bijv de site Yellow-Bricks kom ik, voor een 30/70 lees/schrijf verhouding, al op 15 SAS of 38 SATA disks in R6 om slechts 100 IOPS te halen, maar met de gemeten cijfers weet ik nu nog steeds niet hoeveel ik er nodig heb.

Ik begin een beetje het gevoel te krijgen dat dit nog iets te hoog gegrepen is voor me

Elke input om tot een juiste berekening te komen of een correctie op mijn gedachtengang wordt zeer gewaardeerd.

[ Voor 14% gewijzigd door Ethirty op 14-08-2010 18:49 . Reden: Meet-gegevens toegevoegd ]

[Jelmer]

Ik lees niets over BBWC's, Als deze er niet in zitten, plaats deze. Dit geeft de grootste boost voor weinig geld. Wat betreft IOPS voor kleine files: VEEEEL (snelle) disks. RAID6 zou ik niet doen, teveel performance overhead.

succes ermee in elk geval! Dit soort zaken met krap budget oplossen is knap lastig..

[Zwelgje]

een fatsoenlijke diskdefragger (niet de onboard windows versie ) doet op fileservers met veel files ook wonderen. gebruik zelf altijd PerfectDisk welke je voor 99 dollar al hebt

en idd een grote BBWC doet het ook goed op raid5 systemen (write cache!)

[Ethirty]

Er zit uiteraard al wel BBWC in. De eerste cabinet heeft maar 128MB, de 2e 256MB. Dit gaat sowieso uitgebreid worden naar 512MB of zelfs 1GB FBWC. Defraggen is haast onmogelijk. Het is inmiddels al te ver heen en er is te weinig vrije ruimte beschikbaar. Windows defrag analyse voor 1 disk duurde alleen al 1,5 uur

Het probleem is de omvang van de array nu en in de toekomst. Ik vind R5 voor het soort data een te groot risico. Zelfs met een online spare lopen we teveel risico op het uitvallen van een 2e disk tijdens de rebuild. Misschien maar opdelen in 2 R5 arrays, maar dat gaat weer ten koste van de spindle count.

Maar goed, ik heb dus de meeste moeite met het bepalen van de benodigde performance. Ben bang dat als ik dat niet goed bepaal ik na een flinke investering alsnog te weinig verbetering zie.

[PcDealer]

Ethirty schreef op zaterdag 14 augustus 2010 @ 21:56:

Het probleem is de omvang van de array nu en in de toekomst. Ik vind R5 voor het soort data een te groot risico. Zelfs met een online spare lopen we teveel risico op het uitvallen van een 2e disk tijdens de rebuild. Misschien maar opdelen in 2 R5 arrays, maar dat gaat weer ten koste van de spindle count.

Die kun je weer in mirror zetten. Ik dacht dat de P8x0 recommended is als controller voor de MSA, sowieso de snelste controller.
- Quickspecs MSA60
- Quickspecs P812, deze heeft bovendien RAID6 en andere raid implementaties al standaard gelicenceerd (Smart Array Advanced Pack) en meteen 1GB FBWC (p/n 487204-B21), Meteen maar aan de PW toegevoegd

edit:
pricewatch: HP Smart Array HP Smart Array P812 Controller

[ Voor 6% gewijzigd door PcDealer op 17-08-2010 09:42 ]

[Wim-Bart]

Voor jouw probleem is er geen goedkope oplossing hoe raar het ook klinkt. Je moet eerst bepalen wat je nu daadwerkelijk wilt bereiken en of dat overéénstemt met de vraag vanuit het management.

Er zijn twee methoden:
1. waarbij je aangeeft dat er problemen zijn en dat die opgelost moeten worden. Het management zegt meestal, het werkt toch, dus weinig geld.
2. waarbij je richting je manager aangeeft wat de mogelijke problemen zijn, wat het mogelijke bedrijfsrisico is en wat er voor mogelijk financieel plaatje aan hangt om het op te lossen.

Let op "mogelijke". Wanneer je voor de eerste mogelijkheid gaat, dan heb je twee mogelijkheden:
1. je gaat op zoek naar de "goedkope" oplossing en uiteindelijk wordt jij de schuldige als het over een jaar weer slecht is.
2. Je doet een gedegen onderzoek, legt het probleem bij leverancierS neer en zet twee oplossingen naast elkaar met een advies.

Ik zou zelf voor de tweede gaan. Want ervaring leert, opeens is er wel geld als je kan aantonen met feiten dat de bedrijfsvoering onderuit gaat en dat het bedrijf eens moet investeren in een gedegen oplossing.

En nu even over jouw probleem.
1. Identificeer je data, wat is courant, wat is minder courant en wat is archief.
2. Heb je alleen pure file data of moet je ook IOPS hebben voor bijvoorbeeld SQL, Exchange, Oracle?
3. Bepaal je risico gebieden, bijvoorbeeld wat als archief een dag niet beschikbaar is.
4. Stel een migratiescenario vast en probeer dit in de technische eisen mee te nemen.

Gezien de hoeveelheid data en het globale verhaal er om heen ben ik bang dat je kosten maakt die niet nodig zijn voor bepaalde data eenheden en juist bespaard op de data eenheden die best wel duurder mogen zijn.

Orienteer je ook eens naar level 1, level 2 en level 3 opslag systemen. Een voorbeeld:
level 1, courante data, raid 1 + hot spares op 15K disks,
level 2, minder courante data, raid 5 + hot spares op 10K disks,
level 3, oude data, raid 5 + hot spares op 7200 disks.

Meestal zal de level 1 niet meer dan 2 á 3 TB bedragen, level 2 misschien hooguit 4 tot 5 TB en level 3 de rest. Nadeel, je zit dan wel aan een NetApp of gelijkwaardig vast, maar leveranciers kunnen je vast verder helpen

[SpamLame]

Een heel verhaal Ethirty.


Als ik lees dat de aanvoer van data gaat over maximaal een 100Mb (dus Megabit) WAN connectie, vertaalt zich dat in ~10 Megabyte per seconde. Je disksubsysteem moet dan heel oud of suboptimaal zijn wil ze dat niet aankunnen of ik begrijp je verkeerd.

Wat ik ook niet begrijp is dat als de data cruciaal geacht wordt en bijna niet offline kan, dat je gaat kruidenieren.
Heb je al uitgerekend hoeveel het het bedrijf kost als de data niet beschikbaar is?
EN performance EN beschikbaarheid = $$$
Even voor de vuist weg ((aantal mensen * dagloon + verloren productie/gedorven inkomsten) * aantal dagen offline).

Eigenlijk dus wat Wim-Bart ook zegt.

Van HP engineers heb ik vaak de volgende rekenwaardes gehoord/gelezen voor de IOPS per disk.
SATA 70
FC/SAS 150
Hier zit dan nog geen overhead bij voor je RAID penalty's bij writes, maar geeft een aardige indicatie.

Technische mogelijkheden:
-Netwerk upgraden? (zie bovenaan)
-Schijven gewoon vervangen door SAS
-Hoogste load migreren naar je snelste controller.
-Extra RAID controller plaatsen al dan niet met extra schijf kabinet
-Huidige server ontlasten door functie scheiding/ afsplitsing
-MDS600 (70 spindels in iets van 8 U) enclosure ipv MSA60.

Indien je erg veel spindels voor IO nodig zou hebben, denk dan ook NAS/SAN oplossingen.
NetApp kost je ong 7000 euro voor een FAS2000 serie met ~5TB raw SATA opslag.
HP/EMC etc. breng en soortgelijke oplossingen op de markt.

[Zwelgje]

Ethirty schreef op zaterdag 14 augustus 2010 @ 21:56:
Windows defrag analyse voor 1 disk duurde alleen al 1,5 uur

als dat al zo lang duurt ligt daar gewoon ook een probleem, dat ding is gewoon enorm fragmented, download gewoon even een trial van een commercieel pakket en laat die enkele passes over het volume doen (dit kan gewoon op de achtergrond in idletime) kan je wel een weekje kosten, maar aan het einde van de week is dat ding weer tip top in orde

[PcDealer]

SpamLame schreef op zondag 15 augustus 2010 @ 09:33:

[bulpzame adviezen]
-MDS600 (70 spindels in iets van 8 U) enclosure ipv MSA60.

Die begint vanaf EUR 7.525,00 zonder schijven. Dan is een extra MSA met schijven voor tier 1 op slag + controller goedkoper, lijkt mij.

Indien je erg veel spindels voor IO nodig zou hebben, denk dan ook NAS/SAN oplossingen.
NetApp kost je ong 7000 euro voor een FAS2000 serie met ~5TB raw SATA opslag.
HP/EMC etc. breng en soortgelijke oplossingen op de markt.

Ja, de FAS2020 met sata schijven, maar let op dat je misschien de software packs (voor bijvoorbeeld in een virtuele omgeving) en de maintenance nog apart moet betalen.

HP heeft de P4000 (Lefthand), Stonefly vanaf 10/12K list alles gelicenceerd met sata. Maar binnen de cabinet mix and match met sata, sas en/of ssd.

[ Voor 8% gewijzigd door PcDealer op 15-08-2010 10:29 ]

[Ethirty]

@Wim-Bart: dank, hiermee kan ik wel wat aan de business-kant. Nu de techniek nog.

Wim-Bart schreef op zondag 15 augustus 2010 @ 06:28:
Er zijn twee methoden:
1. waarbij je aangeeft dat er problemen zijn en dat die opgelost moeten worden. Het management zegt meestal, het werkt toch, dus weinig geld.

Dit is wat er al een tijdje speelt. Het werkt en er is - over het geheel genomen - ruimte over, dus lekker laten gaan. Ik ben dus bezig met plan 1.2, maar ben bang voor je 1.1 versie als ik niet met de goede cijfers kan komen. Op dit moment kan ik vis noch vlees maken van de verzamelde gegevens.

SpamLame schreef op zondag 15 augustus 2010 @ 09:33:
Een heel verhaal Ethirty.

Ik wist niet goed hoe ik het verhaal korter kon uitleggen en ik heb nog dingen weggelaten

Als ik lees dat de aanvoer van data gaat over maximaal een 100Mb (dus Megabit) WAN connectie, vertaalt zich dat in ~10 Megabyte per seconde. Je disksubsysteem moet dan heel oud of suboptimaal zijn wil ze dat niet aankunnen of ik begrijp je verkeerd.

Ja, dat klopt, ik had het over Megabits. Veel meer dan dat kan er niet op de server binnenkomen. In een interne procedure kwam ik tegen dat 40GB verplaatsen 7u duurde en daar schrok ik zo van dat ik verder wilde graven. Mijn laptop is sneller

Wat ik ook niet begrijp is dat als de data cruciaal geacht wordt en bijna niet offline kan, dat je gaat kruidenieren.
Heb je al uitgerekend hoeveel het het bedrijf kost als de data niet beschikbaar is?
EN performance EN beschikbaarheid = $$$

Tja, het gaat hier om een backup dienst voor derden. In stricte zin is data dus te reproduceren als het misgaat, maar dan ben je wel de retentie van gewijzigde files kwijt, voor sommige klanten is dat inmiddels jaren aan wijzigingen (virtuele maand en jaar tapes). Het is niet aan de leverancier om te oordelen over hoe belangrijke welke data is en al helemaal niet om daar géén waarde aan te hechten. De klant zal maar een enorm probleem hebben en leverancier moet zeggen: sorry maar die data zijn we kwijt geraakt
Deze moet gewoon een betrouwbare en snelle dienst neerzetten. Het liefst in cluster-vorm met alles extra-super redundant, maar dat gaat financieel nooit gebeuren.

Helaas zit de software hiervoor zodanig in elkaar dat alle data van een klant in zijn geheel bij elkaar moet blijven, ook al wijzigt er maar een paar procent van. Omdat de wijzigingen op blocklevel opgeslagen worden is er ook een hoop disk-activiteit om te bepalen welke files gewijzigd zijn en welke dus ge-upload moeten worden. De meeste files zijn ~2KB, wat dus vooral IOPS vraagt vs brute doorvoorsnelheid, maar er zijn ook files van enkele honderden MB's. Het is dus puur een file-server met ongestructureerde data, geen SQL en geen Exchange.
Tenzij er een laag tussen gezet kan worden die dynamisch kan bepalen of data op level 1,2 of 3 thuis hoort, ben ik bang dat alles level 1 moet blijven.

Technische mogelijkheden:
-Netwerk upgraden? (zie bovenaan)
-Schijven gewoon vervangen door SAS
-Hoogste load migreren naar je snelste controller.
-Extra RAID controller plaatsen al dan niet met extra schijf kabinet
-Huidige server ontlasten door functie scheiding/ afsplitsing
-MDS600 (70 spindels in iets van 8 U) enclosure ipv MSA60.

Indien je erg veel spindels voor IO nodig zou hebben, denk dan ook NAS/SAN oplossingen.
NetApp kost je ong 7000 euro voor een FAS2000 serie met ~5TB raw SATA opslag.
HP/EMC etc. breng en soortgelijke oplossingen op de markt.

In dit geval zijn wij de leverancier, dus ik moet met een gedegen advies komen. Hardware erbij zoeken is ook niet het probleem. Dit soort storage analyse is niet echt iets wat we vaak doen, vandaar dat ik vooral worstel met de meet-gegevens. In 99 van de 100 gevallen is zelfs de simpelste server snel genoeg voor onze klanten. Ik kan ook niet op collega's terugvallen, want die weten er nog minder van. Als ik weet wat er nodig is, dan kan ik gaan shoppen bij de leveranciers om te zien wat er allemaal binnen het totaalplaatje valt.

Er zijn inderdaad zat hardware oplossingen om genoeg spindles en IO aan de server te knopen. De MDS600 had ik ook al naar gekeken en prijstechnisch een beetje in de buurt van 3x een MSA60 (beiden gevuld met 35/36 disks). Ben je wel zo'n €25k lichter en gezien de situatie wil ik toch meer naar een gefaseerde investering toewerken.

Ben wel benieuwd hoe een NetApp SATA-SAN van €7k veel meer IO gaat leveren dan een DAS oplossing met dezelfde capaciteit en spindle count, want dat laatste is nog duurder ook. Heeft dat te maken met de onderliggende logica, dus filesysteem en controller-intelligentie etc?

Edit: @PcDealer. Ik ben bekend met de HP hardware. We zijn zelf ook reseller
Prijstechnisch zou ik in dit geval een P411/1GB FBWC verkiezen boven de P812, maar dan mis je inderdaad weer standaard R6 support die je dan weer bij moet kopen. Kan het even niet vinden, maar volgens mij is de SAAP licentie goedkoper dan het prijsverschil tussen de twee.

[ Voor 3% gewijzigd door Ethirty op 15-08-2010 11:02 ]

[Powermage]

Je zou ook eens naar alternatieve systemen kunnen kijken, oa ZFS bied juist voor jou 'probleem' een oplossing.
Nexenta maakt dan weer een makkelijkere laag omheen.
Dankzij relatief goedkope SSD schijven kan je een enorme performance boost creëren.
Oa tweakers maakt gebruik van het zfs filesystem.

[SpamLame]

PcDealer schreef op zondag 15 augustus 2010 @ 10:27:
[...]
Die begint vanaf EUR 7.525,00 zonder schijven. Dan is een extra MSA met schijven voor tier 1 op slag + controller goedkoper, lijkt mij.

[...]

True, heb ik er alleen maar neergezet indien je een DAS oplossing met veel spindels zou willen

Ja, de FAS2020 met sata schijven, maar let op dat je misschien de software packs (voor bijvoorbeeld in een virtuele omgeving) en de maintenance nog apart moet betalen.

HP heeft de P4000 (Lefthand), Stonefly vanaf 10/12K list alles gelicenceerd met sata. Maar binnen de cabinet mix and match met sata, sas en/of ssd.

Nogmaals true over NetApp.

[SpamLame]

Ethirty schreef op zondag 15 augustus 2010 @ 10:57:

Ja, dat klopt, ik had het over Megabits. Veel meer dan dat kan er niet op de server binnenkomen. In een interne procedure kwam ik tegen dat 40GB verplaatsen 7u duurde en daar schrok ik zo van dat ik verder wilde graven. Mijn laptop is sneller

Dat lees ik als de verbinding is sneller dan 100Mbit, maar door de problemen is het systeem niet in staat om hogere aanvoer dan 100Mbit af te handelen, klopt dat?

Tja, het gaat hier om een backup dienst voor derden. In stricte zin is data dus te reproduceren als het misgaat, maar dan ben je wel de retentie van gewijzigde files kwijt, voor sommige klanten is dat inmiddels jaren aan wijzigingen (virtuele maand en jaar tapes). Het is niet aan de leverancier om te oordelen over hoe belangrijke welke data is en al helemaal niet om daar géén waarde aan te hechten. De klant zal maar een enorm probleem hebben en leverancier moet zeggen: sorry maar die data zijn we kwijt geraakt
Deze moet gewoon een betrouwbare en snelle dienst neerzetten. Het liefst in cluster-vorm met alles extra-super redundant, maar dat gaat financieel nooit gebeuren.

Helaas zit de software hiervoor zodanig in elkaar dat alle data van een klant in zijn geheel bij elkaar moet blijven, ook al wijzigt er maar een paar procent van. Omdat de wijzigingen op blocklevel opgeslagen worden is er ook een hoop disk-activiteit om te bepalen welke files gewijzigd zijn en welke dus ge-upload moeten worden. De meeste files zijn ~2KB, wat dus vooral IOPS vraagt vs brute doorvoorsnelheid, maar er zijn ook files van enkele honderden MB's. Het is dus puur een file-server met ongestructureerde data, geen SQL en geen Exchange.
Tenzij er een laag tussen gezet kan worden die dynamisch kan bepalen of data op level 1,2 of 3 thuis hoort, ben ik bang dat alles level 1 moet blijven.

Ik snap de relatie tussen bovenstaande niet met waar je mij me quote.
Wat ik bedoelde is wat het jou (bedrijf) kost als je storage server er mee kapt in een worst case scenario.
In het geval van een productie bedrijf zie rekensom stukje terug, als je een dienst verzorgt voor derden dan kosten voor herstel en penalty's voor niet naleven van SLA's.
Punt wat ik hier probeer te maken is dat downtime altijd geld kost, de vraag is hoeveel. Als je dat weet, weet je ook of het gegeven budget realistisch is of niet.
Te meer ook omdat je zelf aangeeft dat de data cruciaal is/geacht word en bijna niet offline kan, maar daar een krap budget voor hebt om op te lossen.
Dat is moeilijk tot niet verenigbaar.
Zie ook hier wederom het verhaal van Wim-Bart.

In dit geval zijn wij de leverancier, dus ik moet met een gedegen advies komen. Hardware erbij zoeken is ook niet het probleem. Dit soort storage analyse is niet echt iets wat we vaak doen, vandaar dat ik vooral worstel met de meet-gegevens. In 99 van de 100 gevallen is zelfs de simpelste server snel genoeg voor onze klanten. Ik kan ook niet op collega's terugvallen, want die weten er nog minder van. Als ik weet wat er nodig is, dan kan ik gaan shoppen bij de leveranciers om te zien wat er allemaal binnen het totaalplaatje valt.

Je kan pas weten wat nodig is en gedegen advies geven, als de klant (intern of extern maakt niet zoveel uit) zijn functionele eisen (of belangrijker misschien zijn verwachtingen) duidelijk heeft gemaakt.
-Restore/recovery tijden (RTO)
-Hoeveel dataverlies acceptabel is (RPO)
-Reponse tijden van het systeem (type data igv tiering)
-GB gewenst gekoppeld aan groeiprognose voor een X periode
-IOPS gewenst gekoppeld aan groeiprognose voor een X periode
-etc enz.

Je kan ook adviseren een specialist (of club) in te huren om een advies op te stellen of dat deel uit te besteden aan een specialisten club, aangezien je zelf aangeeft dat er binnen je toko niet veel kennis van dit onderwerp aanwezig is.

Er zijn inderdaad zat hardware oplossingen om genoeg spindles en IO aan de server te knopen. De MDS600 had ik ook al naar gekeken en prijstechnisch een beetje in de buurt van 3x een MSA60 (beiden gevuld met 35/36 disks). Ben je wel zo'n €25k lichter en gezien de situatie wil ik toch meer naar een gefaseerde investering toewerken.

Ben wel benieuwd hoe een NetApp SATA-SAN van €7k veel meer IO gaat leveren dan een DAS oplossing met dezelfde capaciteit en spindle count, want dat laatste is nog duurder ook. Heeft dat te maken met de onderliggende logica, dus filesysteem en controller-intelligentie etc?

Ja onder andere aan het FS, maar ook caching algoritmes en firmware kunnen bijdragen aan hogere performance, maar dat geld niet alleen voor NetApp.

[Skinkie]

Powermage schreef op zondag 15 augustus 2010 @ 10:58:
Je zou ook eens naar alternatieve systemen kunnen kijken, oa ZFS bied juist voor jou 'probleem' een oplossing.
Nexenta maakt dan weer een makkelijkere laag omheen.
Dankzij relatief goedkope SSD schijven kan je een enorme performance boost creëren.
Oa tweakers maakt gebruik van het zfs filesystem.

Lijkt me ook ja. 8 TB aan SATA schijven en RaidZ2 kom je zeker een eind.

[Ethirty]

SpamLame schreef op zondag 15 augustus 2010 @ 11:51:
Dat lees ik als de verbinding is sneller dan 100Mbit, maar door de problemen is het systeem niet in staat om hogere aanvoer dan 100Mbit af te handelen, klopt dat?

Nee, de verbinding met het internet en de switch zijn ook maximaal 100Mbit. Dat is dus de uiteindelijke limiterende factor, maar het disk-systeem kan dat nu al niet aan. Een upgrade in de verbinding zal dus sowieso zinloos zijn zonder eerst het disk-systeem aan te pakken.

Ik snap de relatie tussen bovenstaande niet met waar je mij me quote.

Sorry, ik probeerde meer toelichting op het systeem te geven op basis van wat jij en Wim-Bart schreven. Dat kwam kennelijk niet helemaal goed over. Waar ik dus op doelde is dat ik de waarde van de data hoger inschat dan degene die het platform aan derden verhuurt. Ik ga dit in ieder geval in mijn rapport proberen te benadrukken. Ik weet denk ik wel een gevoelige snaar te raken door een specifieke casus aan te halen mbt SLA-penalty's. Ik had daar nog niet eens aan gedacht.

[Mafketel]

Ik ga mee met een hoop wat hier boven gezegd wordt en wilde nog even wat toevoegen... al dan niet overbodig.

Sorry maar ik begrijp even niet waarom je zegt dat een 100mb wan lijn niet de bottleneck is.

Tevens begrijp ik niet hoe je geen kopie van 5tb aan data kunt maken.

Overigens doet die bak nog iets anders dan bestanden leveren en via welke protocollen?

ik zie dat je al wat meer info hebt gegeven..... Maar je creëert ook nog meer onduidelijkheid

Helaas zit de software hiervoor zodanig in elkaar dat alle data van een klant in zijn geheel bij elkaar moet blijven, ook al wijzigt er maar een paar procent van. Omdat de wijzigingen op blocklevel

samen met

Het is dus puur een file-server met ongestructureerde data, geen SQL en geen Exchange.

Is het nu een fileserver of storage container leveraar?

Hoeveel nieuwe/veranderde data is er per dag? Hoeveel van die 5tb wordt per dag gelezen? dus niet hoeveel moet er van beschikbaar zijn maar echt hoeveel er van gelezen wordt. Dit is van belang voor hoeveel en of cache zin heeft.
Als ik het zo lees wordt voor elke klant de volledige dataset gelezen en maar een klein beetje geschreven.

En wat wordt er weggeschreven op het systeem dat een 100mb wan lijn die disk systemen plat kan trekken?

Worst case for budget hardware zijn heel veel kleine veranderingen overal op de disk. Overigens ook dure controllers vinden dat niet leuk met raid 5 en 6. Wil je performance voor die situatie met 100mb wan link als source van het schijf gebruik met overwegend writes, op goedkoopst mogelijk hardware. Dan zal raid1+0 van het moederbord voldoen. Raid5 of 6 is niet optimaal in zo'n situatie en heel veel duurder. Overigens raad ik dit niet aan in een bedrijfs kritische situatie maar voor de performance is het voldoende

Is er iets anders mis met je config los dat eerst op. Overigens als dit systeem nu plat gaat wat is je overlevings strategie? Gezien het feit dat het zo kritiek is zou je daarvoor al een oplossing moeten hebben.

Hergebruik van die hp p600 is economisch niet verantwoord omdat het een pci-x bus kaart is. gebruik je een ander moederbord => waarschijnlijk geen pci-x meer en meerprijs voor een pci-x bord weegt waarschijnlijk niet op tegen een nieuwe controller op pci-e.

SAS sata verschil aan de disk, is wat mij betreft vooral de mogelijkheid om 1 disk aan 1 of twee controllers tegelijk aan te sluiten. Alle andere verschillen zijn voor de disks minder van belang. Enclosures en controllers hebben meer baat bij sas en zodra je meer dan een paar schijven nodig hebt zou ik daar altijd voor kiezen.

En dat opdelen in 2tb schijven is dat een windows feature? Sorry ik doe dit soort dingen al heel lang niet meer op windows en ben daar een beetje uit.

Overigens, vroeger toen sun nog sun was kon je 60 dagen een Sun Storage 7310 system uitproberen .... misschien een idee. Maar ik ken je budget niet 20K kan wat veel zijn ;0

Na de extra info die je hebt gegeven denk ik dat die unified storage oplossing je wel eens heel wat hoofdbrekens uit handen haalt wel jammer dat je dan wat hp kapitaal vernietiging doet maar je zou dit nog eventueel als backupsysteem kunnen gebruiken, want uit je verhaal maak ik niet op dat als er iets fout gaat dat je direct iets anders hebt staan maar je mag niet offline zijn.


Ik denk dat je een hoop goede hints heb gekregen in alle posts dus ik wil je succes in je zoektocht wensen.

[SpamLame]

Ethirty schreef op zondag 15 augustus 2010 @ 12:40:
[...]

Nee, de verbinding met het internet en de switch zijn ook maximaal 100Mbit. Dat is dus de uiteindelijke limiterende factor, maar het disk-systeem kan dat nu al niet aan. Een upgrade in de verbinding zal dus sowieso zinloos zijn zonder eerst het disk-systeem aan te pakken.

Eens als het systeem nu al niet eens 10 Megabyte ps kan afhandelen zit er iets behoorlijk scheef.
Hoe is het afgelopen met het defragmenteren, heeft dat iets bijgedragen aan winst?
Is de Writeback cache aangezet en komt de verhouding write read over een met het ingestelde?

Sorry, ik probeerde meer toelichting op het systeem te geven op basis van wat jij en Wim-Bart schreven. Dat kwam kennelijk niet helemaal goed over. Waar ik dus op doelde is dat ik de waarde van de data hoger inschat dan degene die het platform aan derden verhuurt. Ik ga dit in ieder geval in mijn rapport proberen te benadrukken. Ik weet denk ik wel een gevoelige snaar te raken door een specifieke casus aan te halen mbt SLA-penalty's. Ik had daar nog niet eens aan gedacht.

Ah ok duidelijk, toko X (jij) adviseert toko A over een mogelijke oplossingen. De SLA's die toko A met zijn klanten heeft afgesproken zijn dan leidend, niet niet weg dat de verwachtingen van toko A en zijn klanten anders kunnen zijn dan de geldende afspraken neem dat mee als ze bekend zijn en zoniet geen dan duidelijk aan wat toko A verwachten kan van hetgeen jij adviseert.

[PcDealer]

Ethirty schreef op zondag 15 augustus 2010 @ 10:57:
[...]

Tja, het gaat hier om een backup dienst voor derden. In stricte zin is data dus te reproduceren als het misgaat, maar dan ben je wel de retentie van gewijzigde files kwijt, voor sommige klanten is dat inmiddels jaren aan wijzigingen (virtuele maand en jaar tapes). Het is niet aan de leverancier om te oordelen over hoe belangrijke welke data is en al helemaal niet om daar géén waarde aan te hechten. De klant zal maar een enorm probleem hebben en leverancier moet zeggen: sorry maar die data zijn we kwijt geraakt
Deze moet gewoon een betrouwbare en snelle dienst neerzetten. Het liefst in cluster-vorm met alles extra-super redundant, maar dat gaat financieel nooit gebeuren.
[...]
In dit geval zijn wij de leverancier, dus ik moet met een gedegen advies komen. Hardware erbij zoeken is ook niet het probleem. Dit soort storage analyse is niet echt iets wat we vaak doen, vandaar dat ik vooral worstel met de meet-gegevens.

Wacht even, leveren jullie de backupdienst?

Edit: @PcDealer. Ik ben bekend met de HP hardware. We zijn zelf ook reseller
Prijstechnisch zou ik in dit geval een P411/1GB FBWC verkiezen boven de P812, maar dan mis je inderdaad weer standaard R6 support die je dan weer bij moet kopen. Kan het even niet vinden, maar volgens mij is de SAAP licentie goedkoper dan het prijsverschil tussen de twee.

Als de P812 100% is, is de P411/512 FBWC 55% en de SAAP 20%. Dus ja, het kan veel geld schelen. Echter, als je de hoogste i/o wilt op de controller, dan moet je de portemonnee trekken.

[Ethirty]

Mafketel schreef op zondag 15 augustus 2010 @ 12:48:
Sorry maar ik begrijp even niet waarom je zegt dat een 100mb wan lijn niet de bottleneck is.
...
Tevens begrijp ik niet hoe je geen kopie van 5tb aan data kunt maken.
...
En wat wordt er weggeschreven op het systeem dat een 100mb wan lijn die disk systemen plat kan trekken?

Zoals beschreven en ook aangegeven met cijfers is het disk-systeem verre van ideeal, zoniet compleet F'ed-up. Met een doorvoersnelheid van 1,6MB/s (40GB in 7u) zou een backup van 5TB dus 38 dagen kosten. Daar valt weinig aan te begrijpen toch, da's gewoon DRAMA. Dit is dus binnen de server zelf, dan gebruik ik de WAN link helemaal niet. Partitie mis-alignment, extreme fragmentatie en een door groei verre van ideale indeling van de disk zijn de oorzaak en dat zijn net die dingen die ik wil veranderen.

Is het nu een fileserver of storage container leveraar?

De server levert een backup dienst aan klanten, dus in die zin is het een storage container. Maar kijk je op de server zelf en wil je daar onderhoud op doen of een backup van maken dan is het gewoon een Windows file server met héél veel bestanden.

En dat opdelen in 2tb schijven is dat een windows feature? Sorry ik doe dit soort dingen al heel lang niet meer op windows en ben daar een beetje uit.

Voor basic disks in Windows is dat inderdaad nog de limiet, maar daar is inmiddels al lang een oplossing voor (GPT). Het is meer een limiet vanuit de software leverancier.

SpamLame schreef op zondag 15 augustus 2010 @ 13:17:
Hoe is het afgelopen met het defragmenteren, heeft dat iets bijgedragen aan winst?
Is de Writeback cache aangezet en komt de verhouding write read over een met het ingestelde?

Heb gister op de gunstigste disk (minste fragmentatie, meeste vrije ruimte) een Windows defrag gestart maar deze loopt nog. De analyse gaf 85% file fragmentatie aan, dus dat zal nog wel even duren

Writeback cache staat aan. Read/write verhouding probeer ik nog te analyseren, maar zoals gemeld kan ik niks met de cijfers die ik heb gemeten. De waardes hiervan liggen zo hoog dat niks op internet beschrijft wat dit nu betekent en ik tot op heden dus nog hélemaal niks nuttigs kan halen uit de Perfmon resultaten over de benodigde IO. Disk queues van 8*10^16, waar de limiet rond de 2 mag liggen doen mij vermoeden dat het systeem dusdanig overbelast is dat de meet-gegevens niet meer bruikbaar zijn. En zonder die analyse zal elke aanschaf een gok zijn.

PcDealer schreef op zondag 15 augustus 2010 @ 16:51:
Wacht even, leveren jullie de backupdienst?

Nee, ik adviseer de leverancier van de backupdient. Wij zelf zijn reseller van HP en leverancier van allerhande diensten.

In een ideale wereld zou je een compleet nieuw systeem opbouwen en dan alle data migreren. Helaas leven we niet in een ideale wereld.

[SpamLame]

Het wachten is eigenlijk op het voltooien van de defrag en het opnieuw verzamelen van gegevens die hopelijk meer info bevatten.

1 advies kan je al meegeven en dat is defrag regelmatig al dan niet met 3rd party tool.

Verder kan je aangeven dat de exorbitant hoge waardes van de diskque aangeven dat het controller disk combi niet opgewassen is tegen de IO's die aangeboden worden, een defrag lost wel wat op maar zal hier niet veel helpen is mijn gevoel.

Uitgaande van de avg. cijfers zou ik kijken naar een 20/80 verhouding read/write gaan.
Indien de IO 100% random is (dus 0% seq.), zou ik gaan voor 100% write omdat er voor read niks meer te cachen valt.
In dit specifieke geval lijkt meer cache beter dan genoeg. Indien mogelijk ondersteunt door SSD zie ZFS-verhaal of dmv. vendor software (LSI CacheCade bv. overigens nog niet in HP OEM jasje gezien)
Maar goed even wachten op de defrag etc is wellicht verstandiger.

[Ethirty]

Na bijna anderhalve dag heeft Windows pas iets van 4% gedefragmenteerd. Heb dat dus maar gestopt en een trial van PerfectDisk gedownload om te zien wat dat gaat opleveren. Het heeft in ieder geval wat meer mogelijkheden mbt het beperken van de IO zodat de rest "gewoon" kan blijven draaien. Het zal wel een paar daagjes gaan duren.

[PcDealer]

SpamLame schreef op zondag 15 augustus 2010 @ 22:25:
In dit specifieke geval lijkt meer cache beter dan genoeg. Indien mogelijk ondersteunt door SSD zie ZFS-verhaal of dmv. vendor software (LSI CacheCade bv. overigens nog niet in HP OEM jasje gezien)

HP heeft de CacheFS, maar dat is HP-UX 11i only, zie ook de NFS Services Administrator’s Guide (PDF).

Iets anders is de HP PCIe IO Accelerators for ProLiant Servers:

The IO Accelerator is an advanced storage device that uses solid state storage technology directly on the PCI bus, assuring high read and write data rates and accelerated application performance. The associated application performance improvements will have a positive impact on business results and the ability to make decisions quickly, resulting in significant cost and time savings.

De prijs is schrikbarend hoog. Voor een HP 320GB MLC PCIe ioDrive 600279-B21, heb je een mooie MSA60 Bundle* met een P812 en dan kun je nog* een Bundle nemen en nog geld over houden.
* Afhankelijk van de Bundle grootte in TB

[lammert]

Zo te lezen gebruik je een proprietary backup oplossing, die gebruik maakt van één of ander "copy-on-write" mechanisme (wellicht windows shadow-copy?). Dit is natuurlijk een uiterst handige feature, maar heeft per definitie een enorme fragmentatie tot gevolg (ZFS heeft hier ook last van). Ik denk dat continue of in ieder geval regelmatig defragmenteren in de background met een fatsoenlijke defragmenter echt veel zal schelen.

En RAID 10 ipv 5 of 6 zal natuurlijk ook veel uitmaken.

[Powermage]

Welke backup oplossing word er trouwens gebruikt?
klinkt als een Ahsay oid? die ondersteund bijvoorbeeld replication via een eigen techniek, je migratie duurt dan misschien wel een weekje voordat alles gerepliceerd is, maar je kan wel relatief simpel om door het er gewoon naast te draaien en zo de data om te zetten, is hij in sync disable je de upload tijdelijk op de 1e server, stop je de 2e server

Wij gebruiken ook ahsay en hebben ongveer de helft aan data set op een niet eens zo spannende setup (simpele raid controller en sata disken) soms is ie wat traag bij grote acties of defragmentaties, maar snachts ontvangt hij gerust een 50mbit aan traffic vanaf diverse servers.

Als je in plaats van traditionele storage gebruik gaat maken van nexenta kan je setup er compleet anders uit zien. met een goede ssd write cache (raid1 van ssd's) kan je natuurlijk enorm veel winst behalen doordat die grote caches de files gewoon snel voor het programma wat het aanvoert enorm snel wegschrijft, en doordat de writes optimaler weg geschreven worden word je raid set veel minder belast wat weer een hoop winst oplevert. Read caches heb je misschien minder aan aangezien er afhankelijk van de software heel veel word uitgelezen, maar afhankelijk van de werking kan het natuurlijk enorm schelen.

Als je een relatief dikke server voor nexenta (supermicro) pakt met een goede quad core (evt uitbreiding naar 2 stuks mogelijk) en 24 gb geheugen, 6 ssd's voor caching en een 16 disken in RaidZ2 (soort raid6) dan koop je dat denk ik inclusief standaard licentie voor minder dan 7k per machine, pak je er 2 dan kan je die ook nog eens met intervallen laten repliceren op block niveau waardoor hij alleen zijn changes gaat syncen, dat moet dan ook vlot gaan. Je kan ook voor een HA functie kiezen, dan heb je hem altijd vervolgens kan je met jbod's vrolijk doorgroeien indien nodig, weer 24 disks posities extra voor 1400 euro erbij plaatsen.

Je moet dan nog wel een windows machine erbij plaatsen om je storage te gebruiken via iscsi bijvoorbeeld, maar dat kan een relatief simpele machine zijn, kan je denk ik onder de 16K klaar zijn,

[SpamLame]

En hoe staat het met de defrag?

[Ethirty]

Die pruttelt lekker door

Er is inmiddels gebleken dat er nog veel meer met het systeem aan de hand is. De batterij van de MSA20 is vandaag vervangen, deze bleek dus ook niet te werken (ff over het hoofd gezien ). Maar nu ik zit te graven in de docu over de MSA20 blijkt dat er allerlei zaken mis zijn met de firmware van dat ding. Er wordt niet goed geregistreerd of de batterij nu goed is of niet en dan wordt de cache uitgeschakeld. Blijkt natuurlijk dat er nooit een firmware update heeft plaatsgevonden. Ook zijn er (recente) artikelen van HP dat de batterijen soms niet goed geplaatst zitten zodat de controller de batterij niet eens registreert. Ook is er een conflict met bepaalde management tools van HP die onterecht aangeven dat HD's in de MSA defect zijn (klopt, ik krijg op 8 van de 12 disks een error). Dat wordt dus even een sessie in het datacenter plannen om dit allemaal zelf te verifiëren en op te lossen. Betreffende firmware is al 2 jaar oud, schiet lekker op zo met dit systeem

Overigens reageert het systeem na de reboot (ivm het vervangen van de batterij) een stuk beter heb ik het gevoel. De Windows interface is in ieder geval een stuk minder 'stroperig'. Kan me niet voorstellen dat dat alleen komt door de registry tweaks die ik heb doorgevoerd (disable8dot3 en disablelastaccess).

De 2e cabinet hangt aan een P600 controller en die gaat redelijk, maar defrag wil daar ook nog niet opschieten. Met uitschieters naar 1M fragments voor sommige files zal het ook best even duren voordat alles weer netjes achter elkaar staat. Als je in de grafische modus kijkt op sommige disks dan is er geen blokje vrije ruimte volledig vrij, terwijl er toch ergens nog dik 100GB tussen de fragments verstopt zit

Powermage schreef op dinsdag 17 augustus 2010 @ 10:00:
Welke backup oplossing word er trouwens gebruikt?
klinkt als een Ahsay oid? die ondersteund bijvoorbeeld replication via een eigen techniek, je migratie duurt dan misschien wel een weekje voordat alles gerepliceerd is, maar je kan wel relatief simpel om door het er gewoon naast te draaien en zo de data om te zetten, is hij in sync disable je de upload tijdelijk op de 1e server, stop je de 2e server

Wij gebruiken ook ahsay en hebben ongveer de helft aan data set op een niet eens zo spannende setup (simpele raid controller en sata disken) soms is ie wat traag bij grote acties of defragmentaties, maar snachts ontvangt hij gerust een 50mbit aan traffic vanaf diverse servers.

Het is inderdaad Ahsay. Replicatie server hangt er ook, maar vanwege de performance problemen heeft dat een tijd lang niet lekker gewerkt. De RPS server hangt nu met een crosscable aan de backupserver (Gbit) en dat lijkt voor dat probleem de oplossing te zijn geweest.

Heb wat tijd op het Ahsay forum rondgehangen, maar daar wordt je niet echt vrolijk van. Veel mensen klagen over performance problemen, vooral zodra klanten grotere datasets willen backuppen. Restores schijnen helemaal drama te zijn. Zelfs met goed onderhouden backupservers met hardware die ver boven die van ons geschaald is gaat een flinke restore job maar met 6-8Mb/s. Iets zegt me dat de software zelf ook niet helemaal efficiënt is, maar dat staat verder los van de problemen waar ik nu mee bezig ben. Ik ben tenslotte helemaal nog niet met de software zelf bezig, slechts met het onderliggende disksysteem.

Ik meld me wel weer als ik het gevoel heb dat er weer een beetje voortgang in zit

of als ik het even niet meer zie zitten

[Mafketel]

Als je dit nu zo allemaal vertelt over dit ding.....
Heb ik echt het idee hoelang het ook moet duren je zal toch een kopie van de data moeten hebben voordat je echt aan het systeem kunt werken.
Die replicatie server zou toch alle data moeten hebben? Je stelt tenminste dat de problemen met crosover kabel verholpen waren.

Kun met deze data niet een tijdelijk gebakje neer zetten met een raid 10 met 5 of 6 tb ruimte, zodat je niet meer te maken hebt met alle "speciale features" van de huidige server.

Ik zou aan zo'n setup persoonlijk niet aan durven raken, 1 ding veranderen ook al zou dat altijd beter moeten zijn kan lawines veroorzaken. Veel slechtere performance kan je met andere hardware niet hebben lijkt mij, dus het tijdelijke gebakje hoeft niets speciaals te zijn.

En over de applicatie, Ik denk dat het toch wel heel belangrijk is om te weten wat er binnenkomt wat er mee gebeurt en wat er weer naar buiten gaat. Met deze gegevens kun je ook al meteen een goede schatting van benodigd systeem maken. Ik neem aan dat je in ieder geval wel weet wat er op de wan lijn binnenkomt aan data?

en 1,6mb/s sorry ik begrijp hem niet, drama of geen drama sommige dingen moeten echt gebeuren. En ik heb ook begrepen dat je in ieder geval de machine een half uur uit mag zetten anders kun je ook niet aan de hardware prutsen

Overigens waar ik ook nog aan dacht.... defragmentatie gaat langer dan 38 dagen duren een kopietje is dus sneller (knipoog is voor 38 dagen verandering in het voordeel van de defragmentatie)

zo'n ashayrps zou je in no time moeten kunnen ombouwen naar een ashayobs als ik de marketing lees.... wat heb je anders aan die replicatiedata. Hoe staat het met die rps machine ... kan die niet even waarnemen?

[ Voor 12% gewijzigd door Mafketel op 17-08-2010 21:55 . Reden: heb wat ashay reclame praat gelezen ]

[Ethirty]

Mafketel schreef op dinsdag 17 augustus 2010 @ 21:37:
Die replicatie server zou toch alle data moeten hebben? Je stelt tenminste dat de problemen met crosover kabel verholpen waren.

Volgens mensen die het ooit nodig gehad hebben is de replicatieserver een gevalletje disaster-only. De 'database' van een useraccount wordt niet mee gesynced en moet dus on-the-fly opgebouwd worden als je het ding wil inzetten. Dan schijn je redelijk wat cpu te verbruiken en het kan ook een paar dagen duren. Da's dus geen optie voor "eventjes". Daarnaast is er vanalles mis met het product RPS an sich, want errors in de backup server worden direct gerepliceerd naar je fallback systeem. data

Kun met deze data niet een tijdelijk gebakje neer zetten met een raid 10 met 5 of 6 tb ruimte, zodat je niet meer te maken hebt met alle "speciale features" van de huidige server.

Dan kan ik beter gelijk in 1x een goede server neerzetten. Daar is nu even geen budget voor.

Ik neem aan dat je in ieder geval wel weet wat er op de wan lijn binnenkomt aan data?

Ik heb het ding nooit eerder beheerd. Ik leer met de minuut meer over het systeem, zoals je kan lezen

en 1,6mb/s sorry ik begrijp hem niet, drama of geen drama sommige dingen moeten echt gebeuren. En ik heb ook begrepen dat je in ieder geval de machine een half uur uit mag zetten anders kun je ook niet aan de hardware prutsen

Zeer heftige fragmentatie en een uitgeschakelde cache zorgen er gewoon voor dat het bij elkaar zoeken van blokken met data erg lang duurt. En ik heb nooit gezegd dat de server helemaal niet uit mocht. Een half uur uit in de daluren dat er geen of nauwelijks backups plaats vinden is wat anders dan het ding een paar dagen offline halen om de boel sneller te optimaliseren.

Overigens waar ik ook nog aan dacht.... defragmentatie gaat langer dan 38 dagen duren

Zolang de server in de lucht blijft en de klanten hun backups kunnen maken zal dát me een worst zijn Het ding draait al zeker een jaar met twijfelachtige performance terwijl alle backups gewoon klaar zijn 's ochtends, dus die paar dagen extra zal wel loslopen. De problemen worden pas merkbaar als een user verhuisd moet worden omdat de disk waar hij op zit te vol zit voor een quota verhoging. Dát wil ik oplossen.

[ Voor 3% gewijzigd door Ethirty op 17-08-2010 22:01 ]

[SpamLame]

Ethirty schreef op dinsdag 17 augustus 2010 @ 20:10:
Die pruttelt lekker door

Er is inmiddels gebleken dat er nog veel meer met het systeem aan de hand is. De batterij van de MSA20 is vandaag vervangen, deze bleek dus ook niet te werken (ff over het hoofd gezien ). Maar nu ik zit te graven in de docu over de MSA20 blijkt dat er allerlei zaken mis zijn met de firmware van dat ding. Er wordt niet goed geregistreerd of de batterij nu goed is of niet en dan wordt de cache uitgeschakeld. Blijkt natuurlijk dat er nooit een firmware update heeft plaatsgevonden. Ook zijn er (recente) artikelen van HP dat de batterijen soms niet goed geplaatst zitten zodat de controller de batterij niet eens registreert. Ook is er een conflict met bepaalde management tools van HP die onterecht aangeven dat HD's in de MSA defect zijn (klopt, ik krijg op 8 van de 12 disks een error). Dat wordt dus even een sessie in het datacenter plannen om dit allemaal zelf te verifiëren en op te lossen. Betreffende firmware is al 2 jaar oud, schiet lekker op zo met dit systeem

In het verleden ook al eens problemen met een MSA20 gehad ivm outdated of bug in firmware, wat resulteerde in het niet meer reageren van de shelf indien er een disk defect raakte.
Indien je kan draai even een firmware maintenance cd om alles (of alleen storage) op het laatste level te krijgen.

[Powermage]

De performance problemen van RPS komen mij idd nogal bekend voor, wij hebben hem tijdens de piekuren enorm gelimiteerd omdat hij anders nogal eens wilde crashen (heel ahsay) of enorm traag werd, maar ik heb het idee dat de sync totaal niet optimaal verloopt als ik die logs altijd bekijk, alsof hij elke ronde gewoon elke file volledig checkt ipv op crc niveau oid.

Ook word inderdaad de database niet gerepliceerd, en met een klant met een flinke historie loopt dat echt in de duizenden bestanden, maar op dat 'euvel' na is het vrij simpel om te switchen tussen

Op het Ahsay forum zie je ook dat veel mensen bijvoorbeeld zelf een Rsync sync zijn gaan gebruiken die ze 1x per dag handmatig laten lopen), denk dat dat ook wel de load enorm kan verbeteren aangezien je niet doorlopend synct.

Wij gaan nu als nieuwe storage een Nexenta systeem in ons DC hangen, primair voor Vmware, daarnaast gaan we experimenteren met hem als storage gebruiken voor het backup systeem (aangezien onze hosts toch vrijwel niet in gebruik zijn in die tijdsframes moet het mbt tot de load niet uitmaken), de sync laten we dan asynchroon draaien naar een 2e nexenta machine, inhoudelijk zullen we de RPS techniek dan ook misschien gaan vervangen voor iets als Rsync oid (ivm dat we een backup willen op een 2e locatie)

[Mafketel]

Ethirty schreef op dinsdag 17 augustus 2010 @ 21:59:
[...]
Volgens mensen die het ooit nodig gehad hebben is de replicatieserver een gevalletje disaster-only. De 'database' van een useraccount wordt niet mee gesynced en moet dus on-the-fly opgebouwd worden als je het ding wil inzetten. Dan schijn je redelijk wat cpu te verbruiken en het kan ook een paar dagen duren. Da's dus geen optie voor "eventjes". Daarnaast is er vanalles mis met het product RPS an sich, want errors in de backup server worden direct gerepliceerd naar je fallback systeem. data

Klinkt als software waar je ech graag mee wilt werken

[...]
Dan kan ik beter gelijk in 1x een goede server neerzetten. Daar is nu even geen budget voor.

Ik had het eigenlijk zo gedacht....Je zet voor €1000 een gebakje neer, En daarna kun je zonder je tijd te verdoen aan een niet optimaal systeem dat ding vanaf nul opbouwen.
Leek mij goedkoper dan de hele tijd tijd er in te stoppen zonder echt iets te kunnen doen en je constant bang moet zijn om live plat te gaan. Maar ja das mijn kijk... Overigens zou je dan ook per klant kunnen migreren.

[...]
Ik heb het ding nooit eerder beheerd. Ik leer met de minuut meer over het systeem, zoals je kan lezen

wij met elke update

[...]
Zeer heftige fragmentatie en een uitgeschakelde cache zorgen er gewoon voor dat het bij elkaar zoeken van blokken met data erg lang duurt. En ik heb nooit gezegd dat de server helemaal niet uit mocht. Een half uur uit in de daluren dat er geen of nauwelijks backups plaats vinden is wat anders dan het ding een paar dagen offline halen om de boel sneller te optimaliseren.

Vergroot dat half uurtje down naar twee uur per dag, dan zou je kunnen beginnen met de partities die de meeste ruimte hebben te defragmenteren. Bedenk dat elke minuut defragmentatie het probleem helpt oplossen.

[...]
Zolang de server in de lucht blijft en de klanten hun backups kunnen maken zal dát me een worst zijn Het ding draait al zeker een jaar met twijfelachtige performance terwijl alle backups gewoon klaar zijn 's ochtends, dus die paar dagen extra zal wel loslopen. De problemen worden pas merkbaar als een user verhuisd moet worden omdat de disk waar hij op zit te vol zit voor een quota verhoging. Dát wil ik oplossen.

Misschien is er dus geen snellere bak nodig maar een net opgezette bak. En dan om het af te maken een stel grotere schijven in plaats van de 3 jaar oude schijven.

[Ethirty]

Vanavond dus de enorm achterstallige firmware update gedaan, maar één van de batterijen is ondanks vervanging nog steeds niet goed, dus nog steeds geen cache. Wel inmiddels door die nieuwe firmware de status van de disks normaal kunnen uitlezen en daar werd ik niet vrolijker van: 3 van de in totaal 16 disks staan op klappen. Morgenochtend vroeg gaat er een mailtje naar de betreffende directieleden dat er knopen doorgehakt moeten worden.

Ik ga hier geen tijd meer in steken. Straks sloop ik met mijn goede bedoelingen de boel nog en dan heb ik het gedaan

[Mafketel]

Succes, en mag ik vragen welke knopen je hebt voorgesteld door te hakken?

[PcDealer]

Ethirty schreef op donderdag 19 augustus 2010 @ 01:01:
Wel inmiddels door die nieuwe firmware de status van de disks normaal kunnen uitlezen en daar werd ik niet vrolijker van: 3 van de in totaal 16 disks staan op klappen.

Zijn de disks nog onder suppoer?

[Ethirty]

Ik wil er een zooi disks bij. Dan kan ik de data van de MSA20 afhalen. Daarna kan de MSA60 evt aan een andere server gehangen worden. Bijkomend voordeel is dat ik een stuk meer IO krijg op het snelste stuk van de server, dus qua schrijfsnelheid zou ik me dan even geen zorgen meer hoeven maken.

Disks hebben 24/7 support contract, maar met de performance problemen zie ik het niet zitten om een array te moeten rebuilden.

[PcDealer]

Ethirty schreef op donderdag 19 augustus 2010 @ 09:47:
[...]
Disks hebben 24/7 support contract, maar met de performance problemen zie ik het niet zitten om een array te moeten rebuilden.

Maar de bijna bij de hemel aangekomen schijven en een koppotte battery wil je toch wel vervangen hoe dan ook?

[ Voor 29% gewijzigd door PcDealer op 19-08-2010 09:56 ]

[Grolsch]

gewoon schijven eruit trekken, en moet jij eens opletten hoe snel er budget is

Je probeert iets te redden, wat niet te redden valt, er zal gewoon een degelijke oplossing moeten komen.

[ Voor 40% gewijzigd door Grolsch op 19-08-2010 11:24 ]

[Petuhr]

Grolsch schreef op donderdag 19 augustus 2010 @ 11:24:
gewoon schijven eruit trekken, en moet jij eens opletten hoe snel er budget is

Nee, de klanten met de problemen van een niet bereikbare backup service opzadelen is de oplossing ....

[Mafketel]

Ethirty schreef op donderdag 19 augustus 2010 @ 09:47:
Disks hebben 24/7 support contract, maar met de performance problemen zie ik het niet zitten om een array te moeten rebuilden.

Array geeft geen jota om wat er op de schijven staat..... dus hier heb je geen last van windows performance problemen.
Mocht het rebuilden wel performance problemen hebben is er in de hardware ook iets niet lekker.

[Ethirty]

Mafketel schreef op donderdag 19 augustus 2010 @ 16:04:
Array geeft geen jota om wat er op de schijven staat..... dus hier heb je geen last van windows performance problemen.
Mocht het rebuilden wel performance problemen hebben is er in de hardware ook iets niet lekker.

No offense, maar volgens mij lees je maar een deel van wat ik schrijf. De cache doet het niet, 2 disks hebben errors, de hardware is niet helemaal lekker.

Ik ga vanavond eens lekker wat voor mezelf doen

[Ethirty]

Nou, mail is kennelijk goed overgekomen. Denk dat het besef er is dat dit niet veel langer kan zo. Mag een voorstel doen voor verbeteringen aan de hardware

Heb nu het volgende verzonnen (HP only):

• nieuwe MSA60 met 12 1TB SAS MDL 7.2K disks (afstappen van SATA voor productie-server. Prijsverschil is minimaal, maar wel een upgrade van 1.5Gbps naar 3Gbps interface)
• nieuwe MSA60 cascaden met oude MSA60 (achter de P600 controller)
• nieuwe array maken en afstemmen van NTFS block size, stripe size en partitie alignment voor optimaliseren read/write acties. Twijfel nog aan R5+hotspare of R6, die laatste kost me voor mijn gevoel nog wat teveel schrijf-performance. Maar aan de andere kant vang ik dat straks op door véél meer cache.
• alle data van MSA20 en oude MSA60 migreren naar nieuwe MSA60 met minimaliseren van downtime serviceverlening
• onderhoudstaak maken voor regelmatig defragmenteren
• oude MSA60 er tussenuit halen en aan SATA based RPS server hangen voor extra storage
• nieuwe server met P812 controller inrichten en nieuwe MSA60 eraan hangen

Waar ik niet helemaal uit kom met de HP documentatie.

• Kan je een gecascade MSA60 stack weer opbreken in losse eenheden
• Kan je die vervolgens veilig verplaatsen naar een andere controller

Dat laatste is op zichzelf mogelijk, mits je let op firmware etc, maar hierbij wordt nergens gesproken over wijzigingen in de MSA-stack zoals ik die bedacht heb. Helaas heeft een P600 maar 1 externe poort dus ik heb in deze variatie alleen de mogelijkheid om te stacken.

Alternatief is de nieuwe server eerst helemaal operationeel maken, maar daarmee vergroot ik de downtime tijdens het migreren van data enorm. Persoonlijk vind ik dat geen goede optie.

Iemand nog suggesties?

[PcDealer]

Let op de MSA60 bundels, die zijn goedkoper dan de MSA, losse disks en je krijgt er een I/O controller bij voor multidomain en multipath verbindingen.

Wat bedoel je met een MSA stack?

[Ethirty]

PcDealer schreef op zaterdag 21 augustus 2010 @ 14:45:
Let op de MSA60 bundels, die zijn goedkoper dan de MSA, losse disks en je krijgt er een I/O controller bij voor multidomain en multipath verbindingen.

Wat bedoel je met een MSA stack?

Ja, die bundels heb ik gezien (ik neem aan dat je de AP714A bedoeld). Maar een 2e I/O module heb ik op dit moment niks aan. Ik moet nog even kijken wat precies goedkoper is.

Met stack bedoel ik het cascaden van de MSA's. Dit kan in een 1+3 config. Zo kan je aan een P600 maximaal 48LFF drives hangen.

[Fiander]

Ik lees dit nu allemaal voor het eerst en heb meteen een paar vragen.
Ik zie dat je 500.000 of meer fragments per bestand hebt ?
Dat je erg veel kleine bestandjes heb ?

Laat me raden, om ruimte op disk te besparen is er NTFS-compressie aangezet ?
Dat zou teminste meteen ook de hoge CPU load verklaren terwijl er slechts max 100Mb data binnen kan komen.

Mocht ik gelijk hebben, is je probleem opgelost waneer je NTFS-compressie uitzet.
Hoewel je dan waarschijnlijk weer een ruimte gebrek hebt.

[PcDealer]

Ethirty schreef op zaterdag 21 augustus 2010 @ 15:24:
[...]

Ja, die bundels heb ik gezien (ik neem aan dat je de AP714A bedoeld). Maar een 2e I/O module heb ik op dit moment niks aan. Ik moet nog even kijken wat precies goedkoper is.

Toevallig heb ik die in een huidige uitrol gebruikt. Die 12TB bundle was goedkoper dan de benodigde 10TB in een d2d2t oplossing. En er zit dus de extra module in.

Voor sata, kun je beginnen vanaf de AG910A 3TB sata bundle. Je zult zien dat de MSA60 enclosure (418408-B21) al duurder is. Ik twijfel overigens of de sata bundels wel een I/O controller extra hebben...

Met stack bedoel ik het cascaden van de MSA's. Dit kan in een 1+3 config. Zo kan je aan een P600 maximaal 48LFF drives hangen.

Ah, I hear you

The MSA60 supports the cascading of shelves in a 1+3 configuration to allow a maximum of 48 drives in an 8U configuration behind each of the two external ports on the HP Smart Array P800, the HP Smart Array E500, HP Smart Array P411 or the HP Smart Array P812 Controllers for a total of 96 drives in 8 enclosures (this single controller port incorporates four lanes for a total max throughput of 12Gb/s for SAS).
http://h18000.www1.hp.com.../12627_div/12627_div.html

De cascade opbreken zal vast kunnen, maar ligt misschien aan hoe de data is opgedeeld: per array of over arrays. Ik heb daar niet snel antwoord op kunnen vinden.

[Ethirty]

PcDealer schreef op zaterdag 21 augustus 2010 @ 16:07:
De cascade opbreken zal vast kunnen, maar ligt misschien aan hoe de data is opgedeeld: per array of over arrays. Ik heb daar niet snel antwoord op kunnen vinden.

Daarom vroeg ik het hier. In de docu van HP wordt daarover helemaal niet gesproken, ook niet in de user manuals van de behuizing, controller of ACU-software.

Fiander schreef op zaterdag 21 augustus 2010 @ 15:35:
Laat me raden, om ruimte op disk te besparen is er NTFS-compressie aangezet ?
Dat zou teminste meteen ook de hoge CPU load verklaren terwijl er slechts max 100Mb data binnen kan komen.

Nee, gelukkig was dit niet ook nog het geval. Dit had ik ook wel heel snel gespot door de mooie blauwe kleur die Windows daar aan geeft

Fragmentatie komt door jarenlange schrijf/delete/schrijf acties met veel kleine bestanden. De grote bestanden die er ook zijn worden hierdoor extra gefragmenteerd opgeslagen omdat er geen aansluitende vrije ruimte meer is. Heb dit dus geprobeerd op te lossen met een defrag, maar dat gaat per volume weken duren met de nodige performance-impact. Omdat ik het zat was risico's te lopen, gooi ik het nu over een andere boeg: zo snel mogelijk die ouwe meuk eruit

[Fiander]

en ipv defragmenteren mbv een usb disk de data weg copieren en daarna weer terug zetten is geen optie ?
waneer je bij het terug copieren blokken hebt welke groot genoeg zijn, is je fragmentatie ook weg.
en dan ben je NU geholpen en kun je in alle rust een vervangend systeem uitzoeken, ipv dat in alle haast doen.


p.s. staat in je verkenner niet stiekum de kleurtjes voor compressie uit?

[ Voor 16% gewijzigd door Fiander op 21-08-2010 17:11 ]

[Ethirty]

Fiander schreef op zaterdag 21 augustus 2010 @ 17:09:
en ipv defragmenteren mbv een usb disk de data weg copieren en daarna weer terug zetten is geen optie ?
waneer je bij het terug copieren blokken hebt welke groot genoeg zijn, is je fragmentatie ook weg.
en dan ben je NU geholpen en kun je in alle rust een vervangend systeem uitzoeken, ipv dat in alle haast doen.

Nee, is nu geen optie. Zou veel te lang duren om de data te verplaatsen (dagen) en in de tussentijd zouden er geen backups gemaakt kunnen worden.

[rapture]

Laat de techniek maar liggen.

Wim-Bart schreef op zondag 15 augustus 2010 @ 06:28:
2. waarbij je richting je manager aangeeft wat de mogelijke problemen zijn, wat het mogelijke bedrijfsrisico is en wat er voor mogelijk financieel plaatje aan hangt om het op te lossen.

Dit is de enige oplossing. Het is nu slechter dan met een onverzekerde auto rondrijden. Reken eens uit hoeveel omzet er misgelopen wordt als het een dagje plat ligt. Hoeveel manuren het kost om de data opnieuw te inputten? Wat met de permanente dataverlies? Hoeveel klanten lopen weg als de data niet beschikbaar is? Ze blijven weg omdat ze betere voorwaarden van een concurrent dankzij deze crash ontdekt hebben. Risico is dan kost van een gebeurtenis * kans dat het voordoet. Net zoals je een 500 euro wagen niet omnium verzekert, moet het IT-budget in verhouding staan tov de risico's. Voer het budget stevig op.

[Ultra]

PcDealer schreef op zaterdag 21 augustus 2010 @ 16:07:
De cascade opbreken zal vast kunnen, maar ligt misschien aan hoe de data is opgedeeld: per array of over arrays. Ik heb daar niet snel antwoord op kunnen vinden.

Als je met array "disk array" bedoelt, dan kun je ze inderdaad zo weer uit elkaar trekken. De cascade is niet meer dan een kabeltje doorlussen.

Voor een MSA60 zou ik een P800 ipv P812 inzetten, de MSA60 praat toch maar met 3Gbps met de controller, al is FBWC een mooie verbetering.

Het nut van dual domain zie ik overigens niet. Extra redundacy op plaatsen waar dat voor DAS weinig interessant is en verder niks voor zover ik weet.

[Ethirty]

rapture schreef op zaterdag 21 augustus 2010 @ 19:03:
Laat de techniek maar liggen.
[...]
Dit is de enige oplossing. Het is nu slechter dan met een onverzekerde auto rondrijden. Reken eens uit hoeveel omzet er misgelopen wordt als het een dagje plat ligt. Hoeveel manuren het kost om de data opnieuw te inputten? Wat met de permanente dataverlies? Hoeveel klanten lopen weg als de data niet beschikbaar is? Ze blijven weg omdat ze betere voorwaarden van een concurrent dankzij deze crash ontdekt hebben. Risico is dan kost van een gebeurtenis * kans dat het voordoet. Net zoals je een 500 euro wagen niet omnium verzekert, moet het IT-budget in verhouding staan tov de risico's. Voer het budget stevig op.

Zoals hierboven al door mij vermeld: ik heb ze al overtuigd, ben al een stadium verder

Ultra schreef op zaterdag 21 augustus 2010 @ 19:54:
Als je met array "disk array" bedoelt, dan kun je ze inderdaad zo weer uit elkaar trekken. De cascade is niet meer dan een kabeltje doorlussen.

Zo had ik het ook bedacht ja, maar ik kan dat dus nergens bevestigd vinden. Nu staat de array info op de disks zelf dus zolang ik 1 array per enclosure hou, dan zou ik dit dus veilig kunnen doen?

Voor een MSA60 zou ik een P800 ipv P812 inzetten, de MSA60 praat toch maar met 3Gbps met de controller, al is FBWC een mooie verbetering.

Tja, de P812 is gewoon weer een generatie nieuwer en volgens mij lopen de prijzen niet eens ver uit elkaar. Er zitten naast de FBWC nog wel meer voordelen aan: 1GB DDR2-800 ipv 512MB DDR2-533. Van PowerPC naar PMC-Sierra RoC, 2x zoveel externe poorten, RAID 50 en 60, etc. Of ik het ooit nodig heb weet ik nu nog niet, maar ik heb sowieso een hekel aan oude nieuwe hardware voor dezelfde prijs

Misschien ga ik ook wel voor een nieuwe D2600 alleen zijn 6G disks nog een beetje prijzig, dus dan win ik nog niks En dat maakt het upgrade-pad trouwens ook weer lastiger, want die kan ik niet aan de bestaande MSA60 knopen.

[Ultra]

Ethirty schreef op zaterdag 21 augustus 2010 @ 20:34:
Zo had ik het ook bedacht ja, maar ik kan dat dus nergens bevestigd vinden. Nu staat de array info op de disks zelf dus zolang ik 1 array per enclosure hou, dan zou ik dit dus veilig kunnen doen?

Ja.

Misschien ga ik ook wel voor een nieuwe D2600 alleen zijn 6G disks nog een beetje prijzig, dus dan win ik nog niks En dat maakt het upgrade-pad trouwens ook weer lastiger, want die kan ik niet aan de bestaande MSA60 knopen.

D2600 kan aan de P812 en een MSA60 ook. Cascade hoeft niet, je hebt 4 poorten .
Bij HP SFF disks zijn de 6G al goedkoper, dus ik verwacht geen groot prijsverschil bij LFF.

[PcDealer]

Daarbij kun je gewoon 6G in een 3G enclosure stoppen. Misschien wel letten op de dual sas connector op de disk, dat die ook past.

[ Voor 41% gewijzigd door PcDealer op 21-08-2010 20:52 ]

[A3_h]

Ondertussen al je degraded disken vervangen???.

[Ethirty]

Ze zijn gelukkig nog niet degraded, alleen rapporteren ze fouten. HP heeft een mooie feature die aangeeft zodra een disk écht op het punt stuk te gaan (predictive failure) en dan mag je ze al binnen je onderhoudscontract vervangen.

Gister een labje opgezet thuis in VMware. Servertje met de backup software en 2 500GB datadisks draaiende op 1 fysieke sata-schijf. Vervolgens vanaf de laptop via Wifi een berg data daar naartoe gebackupped via de backupclient. Snelheid was goed te noemen (maar de disks waren natuurlijk nog helemaal leeg, dus nog geen fragmentatie). Na een jobje van 50GB was vdisk nummer 1 al voor 50% gefragmenteerd en dat met een backup van wat iso's, een mkv, wat avi files en een berg kleinere office documenten

Wie bepaald er nou eigenijk waar data wordt weggeschreven op disk, Windows zelf of de applicatie? Want daar valt in een productieomgeving niet tegenop te defragmenteren

[SpamLame]

Ethirty schreef op zondag 22 augustus 2010 @ 12:50:
Ze zijn gelukkig nog niet degraded, alleen rapporteren ze fouten. HP heeft een mooie feature die aangeeft zodra een disk écht op het punt stuk te gaan (predictive failure) en dan mag je ze al binnen je onderhoudscontract vervangen.

Gister een labje opgezet thuis in VMware. Servertje met de backup software en 2 500GB datadisks draaiende op 1 fysieke sata-schijf. Vervolgens vanaf de laptop via Wifi een berg data daar naartoe gebackupped via de backupclient. Snelheid was goed te noemen (maar de disks waren natuurlijk nog helemaal leeg, dus nog geen fragmentatie). Na een jobje van 50GB was vdisk nummer 1 al voor 50% gefragmenteerd en dat met een backup van wat iso's, een mkv, wat avi files en een berg kleinere office documenten

Wie bepaald er nou eigenijk waar data wordt weggeschreven op disk, Windows zelf of de applicatie? Want daar valt in een productieomgeving niet tegenop te defragmenteren

OS/FS bepalen waar de data komt, maar op een lager nivo is het de disk die bepaalt waar de data komt.
Volg je het topic een tijdje niet, maag je een neiwue oplossing neerzetten.
Ik zeg goed gedaan gozer.

[lammert]

Ethirty schreef op zondag 22 augustus 2010 @ 12:50:
Wie bepaald er nou eigenijk waar data wordt weggeschreven op disk, Windows zelf of de applicatie? Want daar valt in een productieomgeving niet tegenop te defragmenteren

Ik ben niet bekend met Ahsay, maar het moet haast wel dat zij een copy-on-write mechanisme gebruiken. Ieder copy-on-write filesystem heeft per definitie last van fragmentatie, of het nou NTFS, ZFS, BTRFS, XFS of één of ander proprietary Ahsay filesystem is, dat maakt niet uit. Defragmenteren, snelle disken en veel controller cache is het enige dat helpt.

[axis]

En trouwens met fatsoenlijke commerciele pakketten zoals Diskeeper Server plan je niet echt meer een defragmentatie in, maar die defraggen continu on-the-fly.. Werkt erg goed, zeker aan te raden voor een windows fileserver waar veel deletes/creates op plaatsvinden.

[Ethirty]

Updatetje: die MSA20 is echt een kreng. Maandag weer beide batterijen laten vervangen en omdat ik er nu zelf bij was gelijk de status gechecked. Geen errors en de melding 'charging' zoals je mag verwachten. Een paar uur later alles helemaal goed en cache weer ingeschakeld. Ik blij

Check ik net, weer een batterij error, weer geen cache meer

Maar eens informeren of ze al een beslissing hebben genomen over wat ze willen aanschaffen.

[Guru Evi]

Wat is veel/weinig geld? Als je systemen actief moeten blijven dan zou ik gewoon een rsync (of een andere synchronisatie) naar je nieuw systeem doen tot op het moment dat je het systeem enkele uurtjes kunt uitzetten en dan opnieuw rsync (die veel sneller zal gaan).

Ivm IOPS: Een gemiddelde SATA/SAS schijf op 7200rpm geeft 100-150 IOPS per schijf. Als je RAID5 of 6 gebruikt krijg je minimaal 150 IOPS per array voor synced write op blocks die het volledige array gebruiken, read kan iewat sneller behalve als je de data moet herbouwen. Daarvoor dat RAID5/6 nooit gebruikt wordt voor een database - een stripe over enkele RAID1's gaat veel sneller. De effectieve snelheid zal een stuk hoger liggen want een enkele block ligt meestal niet over alle schijven heen, er is hoogstwaarschijnlijk een of andere cache die al stukken heeft en niet alle schijven moeten hun koppen verzetten.

Daarnaast kan je misschien enkele SSD's als read en write cache gebruiken. Dit kan bijvoorbeeld met ZFS. Nexenta is een goede verkoper van een ZFS-centric distributie en je kan het ofwel zelf bouwen of een systeem aankopen waar je dan volumes via FibreChannel of iSCSI (of NFS/SMB) deelt. Ik heb mijn systeem zelf gebouwd en heb met 38 goedkope 2TB SAS schijven en 4 SSD's een 3x12 RAID6 (~50TB) met 2 hotspares systeem dat een dubbel gigabit kan vol smijten (gemiddeld 1000-1500 iops in productie). Het volledige (dubbel redundant) systeem koste me 20k wat een schijntje is vergeleken met andere systemen.

Voor ~10TB (wat jij nodig hebt) kun je gewoon een kastje kopen voor 24 schijven en daarin een relatief goedkoop Xeon systeem inproppen met 12GB RAM (~2000 euro), en 20 1TB SATA (~2000 euro) schijven (2 x 8 in RAID6 voor data, 2 in RAID1 voor boot en 2 spares), 4 SSD's en een goedkoop LSI SAS controller (~2000 euro). Dan de volumes exporteren via iSCSI of NFS. De kosten gaan tussen de 6 en 8000 euro zijn - op zijn minst (in de slechtste omstandigheden) krijg je er 300 IOPS uit, in de meeste gevallen zul je er 500-1000 IOPS moeten krijgen of meer.

[ Voor 27% gewijzigd door Guru Evi op 31-08-2010 18:28 ]

[Verwijderd]

Guru Evi schreef op dinsdag 31 augustus 2010 @ 18:18:
Wat is veel/weinig geld? Als je systemen actief moeten blijven dan zou ik gewoon een rsync (of een andere synchronisatie) naar je nieuw systeem doen tot op het moment dat je het systeem enkele uurtjes kunt uitzetten en dan opnieuw rsync (die veel sneller zal gaan).

Ivm IOPS: Een gemiddelde SATA/SAS schijf op 7200rpm geeft 100-150 IOPS per schijf. Als je RAID5 of 6 gebruikt krijg je minimaal 150 IOPS per array voor synced write op blocks die het volledige array gebruiken, read kan iewat sneller behalve als je de data moet herbouwen. Daarvoor dat RAID5/6 nooit gebruikt wordt voor een database - een stripe over enkele RAID1's gaat veel sneller. De effectieve snelheid zal een stuk hoger liggen want een enkele block ligt meestal niet over alle schijven heen, er is hoogstwaarschijnlijk een of andere cache die al stukken heeft en niet alle schijven moeten hun koppen verzetten.

Daarnaast kan je misschien enkele SSD's als read en write cache gebruiken. Dit kan bijvoorbeeld met ZFS. Nexenta is een goede verkoper van een ZFS-centric distributie en je kan het ofwel zelf bouwen of een systeem aankopen waar je dan volumes via FibreChannel of iSCSI (of NFS/SMB) deelt. Ik heb mijn systeem zelf gebouwd en heb met 38 goedkope 2TB SAS schijven en 4 SSD's een 3x12 RAID6 (~50TB) met 2 hotspares systeem dat een dubbel gigabit kan vol smijten (gemiddeld 1000-1500 iops in productie). Het volledige (dubbel redundant) systeem koste me 20k wat een schijntje is vergeleken met andere systemen.

Voor ~10TB (wat jij nodig hebt) kun je gewoon een kastje kopen voor 24 schijven en daarin een relatief goedkoop Xeon systeem inproppen met 12GB RAM (~2000 euro), en 20 1TB SATA (~2000 euro) schijven (2 x 8 in RAID6 voor data, 2 in RAID1 voor boot en 2 spares), 4 SSD's en een goedkoop LSI SAS controller (~2000 euro). Dan de volumes exporteren via iSCSI of NFS. De kosten gaan tussen de 6 en 8000 euro zijn - op zijn minst (in de slechtste omstandigheden) krijg je er 300 IOPS uit, in de meeste gevallen zul je er 500-1000 IOPS moeten krijgen of meer.

Ik denk dat een serieus gesprek met een storage leverancier beter is voor de continuiteit van het bedrijf van de topic starter.

Serieuze candidaten zijn HP, NetApp, EMC.

Verder kan ik je uit eigen ervaring vertellen dat SATA niet zo'n goed idee is qua performance en betrouwbaarheid. En ik zou ZEKER RAID 6 kiezen ... vooral bij SATA ! Ik heb al eens veel Terabytes zien gaan toen er nog een disk met pensioen ging tijdens de rebuild van de RAID 5 set. Oh en rebuild tijd van sata disken, vooral grote duurt even ... ongeveer 8 uur per Terabyte als je een normale controller hebt.

Service contract is ook handig als je 's nachts rustig wil slapen ... ja het kost geld maar levert een hoop op en neemt een hoop zorgen weg. (probeer nog maar eens na 3 jaar een spare disk te krijgen in je zelfbouw set van hetzelfde type)

Betrouwbaarheid en snelheid kosten nu eenmaal geldt en er zijn weinig shortcuts.

[Mafketel]

Verwijderd schreef op maandag 06 september 2010 @ 00:13:
[...]

Service contract is ook handig als je 's nachts rustig wil slapen ... ja het kost geld maar levert een hoop op en neemt een hoop zorgen weg. (probeer nog maar eens na 3 jaar een spare disk te krijgen in je zelfbouw set van hetzelfde type)

Betrouwbaarheid en snelheid kosten nu eenmaal geldt en er zijn weinig shortcuts.

ipv sla ... extra disks meteen aanschaffen en eventueel na 1 2 of 3 jaar preventief alle schijven vervangen, en dat gewoon bij aanschaf prijs incalculeren.

[nielsl]

Mafketel schreef op maandag 06 september 2010 @ 12:16:
[...]

ipv sla ... extra disks meteen aanschaffen en eventueel na 1 2 of 3 jaar preventief alle schijven vervangen, en dat gewoon bij aanschaf prijs incalculeren.

Dat is natuurlijk typische geldverspilling. MTBF voor server disken ligt tegenwoorden op 1.000.000+ uren, in een jaar zitten nog geen eens 10.000 uren. Nu is MTBF geen garantie dat je schijven ook zolang blijven werken, maar om nu evenveel reserveschijven op de plank te hebben liggen als dat er in je Storage device zitten lijkt mij een beetje overdreven, zeker in combinatie met een goede backup en voldoende redundancy. Enkele schijven op de plank als spare part icm een SLA lijkt mij economisch rendabeler.

[Grolsch]

Ik denk dat de kans op data verlies groter is bij het "preventief" vervangen van schijven dan vervangen als ze kapot zijn.

Ik heb het ook nog nooit iemand zien doen, elke 2 a 3 jaar preventief schijven vervangen

[Guru Evi]

Ik heb ook nog nooit van 'preventief' schijfvervangingen uitvoeren - je hebt een grote(re) kans dat andere schijven het opgeven tijdens je rebuild.

Daarnaast, MTBF geeft niet aan hoe lang een schijf het kan uithouden. Als je dit zou geloven zouden we nooit schijven moeten vervangen (10 jaar of langere levensduur). Wat je wilt weten is je MTTDL (Mean Time To Data Loss) zoals hier is uitgelegd: http://blogs.sun.com/rell...mendations_space_vs_mttdl

Ook voor de SATA-haters: Tegenwoordig is er geen verschil tussen Enterprise SATA en Enterprise SAS behalve dan het bordje op de onderkant van de schijf, mechanisch gezien zijn ze niets verschillend. Wat je niet wilt is een Desktop SATA in je server (behalve voor grote aantalen in een lage kost on-disk backup).

Kijk ook eens naar de papers van Google (en anderen) betreft het overleven van schijven op een grote schaal zodat je kunt uitrekenen hoeveel schijven je daadwerkelijk in een RAID array wilt.

Als je niet weet waar je aan begint, inderdaad beter een technologiebedrijf vragen maar laat je niet de praatjes van EMC of NetApp verkopen (zoals de SATA < SAS < FC < "Wij van WC Eend" schijven/firmware sprookjes) die al te graag een array verkopen die 10 of 20x te duur is voor wat je nodig hebt. Tegenwoordig kun je al een groot aantal IOPS krijgen uit een eenvoudig SAS array dankzij goedkopere schijven en SSD modules zonder al te veel uit te geven.

[Mafketel]

misschien toch iets meer woordjes typen....

Om het: „ik kan de dezelfde disken niet meer krijgen”, te ondervangen, een aantal extra op de plank leggen. En dan in een hoeveelheid wat er verwacht dat er stuk gaat in de tijd dat het gebruikt wordt... Ik weet niet wat dat is op het moment maar 10% ofzo?

Dan preventief disken vervangen... Ik had eigenlijk het idee dat

1. Elke goede hardware raid controller een clone van een disk kon maken zodat bij de eerste smart errors je de schijf zou kunnen verwijderen.... of is dit alleen maar in zfs geïmplementeerd?
   Waardoor je dus niet met het probleem van less redundancy zit.
2. Je na een bepaalde tijd niet de disken vervangt door gelijke schijven, maar door de op dat moment in de markt gelijke prijzen schijven(afhankelijk van het van te voren ingecalculeerde budget natuurlijk). Zodat je dus niet alleen de gebruikte schijven vervangt door nieuwe maar dus ook snelheid en capaciteit verhoogt. Eventueel zou je nog nog even kunnen nadenken over welke onderdelen nog meer als limiterend kwa levensduur kunnen zijn.

Waarbij ik dus vooral punt 2 als leuk extraatje meenam bij de knipoog preventief vervangen. En ik vindt het ook vreemd dat iedereen zo bang is om een schijf te vervangen..... Dat is toch de reden dat je raid hebt.... dat je kunt doorwerken als er een schijf stuk gaat. En die dan kunt vervangen en niet bang bent om een schijf te vervangen als deze niet meer 100% is. Mocht er dan een 2de schijf plat gaan waarbij ik toegeef dat de kans groter is door de hoge belasting als er een rebuild gedaan moet worden.Maar om het maar niet te vervangen om deze reden is dan toch alleen maar uitstel van executie.... Die tweede schijf gaat het ook binnenkort begeven met of zonder rebuild. Voor dat scenario heb je backups.

Ohja voordeel van schijven op de plank is natuurlijk dat dit bijna altijd sneller is dan wat voor sla dan ook. En je niet van iemand anders afhankelijk bent..... wel natuurlijk alles netje documenteren zodat je na een half jaar wat anders te hebben gedaan je snel en correct de boel vervangt.

En preventief vervangen in de markt.... Meestal wordt de hele machine vervangen... Dus ik zie het wel gebeuren. Maar om om een aantal redenen heb ik het idee dat het voor disk systemen het misschien niet nodig is in de nabije toekomst. Waarbij de belangrijkste reden is dat de hardeschijf op dit moment een hele zwakke schakel is in de huidige systemen, samen met condensators(wordt nu weer wat meer op gelet) en lagers van ventilatoren(gelukkig geen werkend of stuk maar na bepaalde tijd langzaam afnemend).

[ Voor 13% gewijzigd door Mafketel op 08-09-2010 11:09 ]

[CMG]

[offtopic]
Leuk topic om te lezen... houd je ons op de hoogte?
[/offtoppic]

[Ethirty]

Toch maar alvast even een kleine update.

Ik zit nog steeds op een officieel 'go' te wachten, maar het plan wat er nu ligt is om de hele server te gaan vervangen en daarover is men positief. Dus een nieuwe snellere server (quad-core) met meer intern geheugen, een nieuwe snelle controller en een nieuwe disk-array met 12 1TB SAS (ja, geen SATA meer ) disks voor 10TB netto opslag. De hardware die nog mee kan verhuist naar het backup systeem, die heeft met de toegenomen capaciteit ook extra ruimte nodig.

Ik twijfel nog een beetje tussen 2 arrays met elk 6 disks of 1 array met 11 disks en een hotspare. Ik neig naar het laatste. Hopelijk is er begin volgende week akkoord over de financiën zodat we kunnen gaan bestellen en dan kan ik hopelijk binnen 1 à 2 weken gaan beginnen met opbouwen en testen.

[Coen Rosdorff]

Volgens mij wil je met dit backup pakket naar veel meer schijven toe.
Door het werken met zoveel kleine losse files en hoge concurrency wil je veel iops hebben.

Van twaalf sata naar twaalf sas disks is dan eigenlijk geen upgrade. Liever 24 sata disks dan 12 sas schijven zou ik zeggen.

[PcDealer]

Coen Rosdorff schreef op zondag 12 september 2010 @ 01:50:

Van twaalf sata naar twaalf sas disks is dan eigenlijk geen upgrade. Liever 24 sata disks dan 12 sas schijven zou ik zeggen.

Is dat niet wat kort door de bocht? Sata is typical 7,2k tpm en SAS 10 of 15K. En waarschijnlijk ook betere logica geschikt voor in een enterprise omgeving zoals cache en andere verbeteringen.

[Mafketel]

Kort door de bocht? ....
Hoeveel 1tb sas drives die meer dan 7200rpm draait zijn er op de markt?

En ja er kan een verschil in snelheid van de schijf bij sas sata zijn, maar dit zal niet veel zijn. Voordelen sas tov sata liggen op een ander vlak.
Meer spindles meer io..... maar gezien de belasting vraag ik mij nog steeds af of raid 10 niet een betere optie is?

Anyway ..... ik ga wel uit van enterprise schijven natuurlijk. Desktop schijven hebben een andere optimalisatie en soms iets andere constructie.

[Ethirty]

Nja, het zijn vanwege het budget wel midline SAS disks (7.2k) geworden, maar we gaan nu naar een array met meer disks en een controller met veel meer cache. Bovendien hebben de midline SAS disks betere specs dan de huidige oude SATA disks. Daarnaast ga ik deze keer letten op performance penalties als partitie-alignment, stripe- en blocksize en hebben we straks wél werkende cache

Hieronder een tabelletje (met van de huidige situatie de traagste array van het hele stel)

	Nu	Straks
RPM	7200	7200
seek	9ms	7,4ms
interface	SATA 133Mbps	SAS 3Gbps
array	8x in R6	11x in R5
capaciteit	1.5TB (>90% vol)	10TB (<50% vol)

[_JGC_]

11x in RAID5? En dan 1TB per stuk? Ik weet niet hoe snel een HP controller gaat rebuilden, en zeker niet met dusdanig veel I/O op die controller, maar houd er rekening mee dat je gewoon 24 uur bezig bent met rebuilden als er een disk kapot gaat, en daarnaast heb je nog 10x1TB aan sectors waarvan er maar 1 onleesbaar hoeft te zijn om je rebuild te laten mislukken. Voor dergelijke grote arrays zou ik voor de veiligheid alleen al gewoon RAID6 doen.

[PcDealer]

Waarom 3G sas als 6G sas weinig in prijs uitmaakt?

[ Voor 10% gewijzigd door PcDealer op 12-09-2010 14:32 ]

[Ethirty]

_JGC_ schreef op zondag 12 september 2010 @ 14:24:
11x in RAID5? En dan 1TB per stuk? Ik weet niet hoe snel een HP controller gaat rebuilden, en zeker niet met dusdanig veel I/O op die controller, maar houd er rekening mee dat je gewoon 24 uur bezig bent met rebuilden als er een disk kapot gaat, en daarnaast heb je nog 10x1TB aan sectors waarvan er maar 1 onleesbaar hoeft te zijn om je rebuild te laten mislukken. Voor dergelijke grote arrays zou ik voor de veiligheid alleen al gewoon RAID6 doen.

Tja, daar zat ik dus ook nog over te twijfelen: 2 RAID5 arrays van elk 6 disks, 1 RAID5 van 11 disks met hotspare of 1 RAID6 van 12 disks. Ik ben qua R6 een beetje 'bang' voor de performance. Ik zoek een beetje de beste balans tussen performance en betrouwbaarheid. Er komen sowieso 2 logische disks op de array(s) om de data wat beter te kunnen managen.

PcDealer schreef op zondag 12 september 2010 @ 14:31:
Waarom 3G sas als 6G sas weinig in prijs uitmaakt?

Omdat SAS MDL 3G maar iets duurder is dan SATA. Als ik zo blijf beredeneren is een 10k drive maar weer iets duurder dan een 7.2k drive en voor je het weet is de hele setup 2-3x zo duur

Daarnaast is het migratieplan voor de data gebaseerd op de MSA60, dus om daar 6G disks in te stoppen is niet interessant.

[CMG]

Ethirty schreef op zondag 12 september 2010 @ 15:03:
[...]

Tja, daar zat ik dus ook nog over te twijfelen: 2 RAID5 arrays van elk 6 disks, 1 RAID5 van 11 disks met hotspare of 1 RAID6 van 12 disks. Ik ben qua R6 een beetje 'bang' voor de performance. Ik zoek een beetje de beste balans tussen performance en betrouwbaarheid. Er komen sowieso 2 logische disks op de array(s) om de data wat beter te kunnen managen.


[...]

Omdat SAS MDL 3G maar iets duurder is dan SATA. Als ik zo blijf beredeneren is een 10k drive maar weer iets duurder dan een 7.2k drive en voor je het weet is de hele setup 2-3x zo duur

Daarnaast is het migratieplan voor de data gebaseerd op de MSA60, dus om daar 6G disks in te stoppen is niet interessant.

RAID 10 is beide; performance + security... ik zit thuis met 4 1TB disks in een RAID 10, daar vind ik RAID 5 al te gevaarlijk; ik kan me niet voorstellen dat je voor een backupdienst zelfs maar overweegt met zo'n groot aantal disks een RAID 5 of 6 array op te gaan bouwen...

[Dronium]

@CMG
Ook een Raid 10 kan met 2 kapotte disks al naar de haaien zijn, zoveel gevaarlijker is Raid 5 volgens mij dan ook niet.
@Ethirty
Bij de laatste tests die ik gezien heb krijg met Raid 6 vooral een performance dip bij sequential Writes en in mindere mate bij sequentail writes, performance R6 was 40 tot 120%. Bij Random Reads en Writes was de Raid6 200 tot 600+% sneller. Dat is bij een vergelijk tussen 4x Sata disk in Raid 10 (local) en 8x Sas disk in Raid6 (iSCSI).
Misshien heb ik maandag gegevens over die iSCSI storage voor Raid5 en Raid 10.

[_JGC_]

Op een beetje fatsoenlijke controller met fatsoenlijke WB-cache is het verschil tussen RAID5 en RAID6 minimaal. Ik heb liever RAID6 zonder hotspare dan RAID5 met. Leesperformance zal dan ook hoger zijn, aangezien je een disk extra hebt. Degraded RAID6 hoeft op zich niet trager te zijn dan RAID5, maar het is maar net hoe je controller omgaat met cache: degraded array zonder WB-cache is triest qua performance, snap niet hoe fabrikanten dat veilig kunnen noemen, aangezien je rebuild dan ook flink langer gaat duren.
RAID10 is in feite gewoon RAID0 over RAID1 arrays. In theorie mag de helft van je disks uitvallen bij RAID10, maar dan moeten dat wel specifieke schijven zijn. Als er 2 disks uit hetzelfde RAID1 clustertje uitvallen ben je alsnog alles kwijt. Laatst trok ik bij een degraded RAID10 array per ongeluk de verkeerde schijf eruit. Niet dat die server echt boeide qua data of uptime, maar had het geluk dat het net een van de disks was die ik er nog wel uit mocht trekken.
Over het algemeen is RAID10 overigens trager dan RAID5 en RAID6 als het op het lezen van data aankomt, maar dat is maar net wat je controller doet. De meesten negeren de 2e disk bij RAID1 arrays gewoon compleet als er gelezen wordt.

[SpamLame]

Als ik de toepassing (backup) zie, zou ik voor small writes geoptimaliseerde settings gaan.

[Ethirty]

CMG schreef op zondag 12 september 2010 @ 21:47:
RAID 10 is beide; performance + security... ik zit thuis met 4 1TB disks in een RAID 10, daar vind ik RAID 5 al te gevaarlijk; ik kan me niet voorstellen dat je voor een backupdienst zelfs maar overweegt met zo'n groot aantal disks een RAID 5 of 6 array op te gaan bouwen...

RAID 10 is veel te kostbaar, ik zou dan al 24(!) disks nodig hebben voor dezelfde 10TB. Dan kan ik beter RAID50 of zelfs RAID60 gebruiken, dan heb ik 20TB

RAID5/6 is veel gebruikelijker dan RAID10 voor grote hoeveelheden data. RAID10 is vanwege de kosten vooral gericht op hoge performance (oa database logs, etc)

SpamLame schreef op maandag 13 september 2010 @ 15:43:
Als ik de toepassing (backup) zie, zou ik voor small writes geoptimaliseerde settings gaan.

Dat was ook mijn idee, moet alleen nog even uitzoeken wat de juiste settings daarvoor zijn.

[Grolsch]

en daarbij, kan bij het falen van 2 schijven ook een RAID10 set al z'n data kwijt zijn.
Dan zou ik ook liever voor een RAID5 gaan.

[_JGC_]

Bij RAID10 mag met een beetje geluk 50% van je disks uitvallen, maargoed, dan moet je het geluk hebben dat er niet 2 schijven uit een RAID1-groepje sterven.

Wat betreft RAID5 vs RAID6:
http://www.zdnet.com/blog...2?tag=mantle_skin;content

Neem dat artikel eens door en bepaal dan of je nog voor RAID5+HS of gewoon RAID6 gaat. Voor mij de reden om voor grote storage arrays altijd RAID6 te gebruiken.

RAID6 heeft over het algemeen 10% lagere performance dan RAID5 bij writes, bij reads is de performance hetzelfde. Je kunt ervoor kiezen om je hotspare met RAID6 gewoon in het array op te nemen, aangezien je degraded RAID6 array in principe gewoon net zoveel bescherming biedt als een gezond RAID5 array en je niet per direct met disks op hoeft te draven.

[Ethirty]

_JGC_ schreef op woensdag 15 september 2010 @ 08:59:
Wat betreft RAID5 vs RAID6:
http://www.zdnet.com/blog...2?tag=mantle_skin;content

Neem dat artikel eens door en bepaal dan of je nog voor RAID5+HS of gewoon RAID6 gaat. Voor mij de reden om voor grote storage arrays altijd RAID6 te gebruiken.

Mooi artikel. Had eigenlijk al gekozen en ga nu definitief voor RAID6. De switch van SATA naar SAS moet me ook iets beter beschermen door een betere URE ratio.

De uitbreiding in cache van 128MB naar 1GB en de overgang van 1e gen SATA drives (ATA133) naar SAS 3G drives compenseren het verlies in performance ruim en ik verwacht hoe dan ook een enorme boost in ruwe performance. Of ik de backup applicatie die extra performance ook kan laten gebruiken zullen de tests met het nieuwe systeem moeten gaan uitwijzen.

[PcDealer]

Welke software?

[Ethirty]

Ahsay, dat was hier al langs gekomen. Wel bijblijven hè

Ahsay is het meest uitgebreide online backup applicatie voor resellers/oems die ik tot nu toe ben tegengekomen. Maar het is gebaseerd op Java/Tomcat en is mede daarom een draak van een applicatie.

[PcDealer]

Ethirty schreef op woensdag 15 september 2010 @ 23:20:
Ahsay, dat was hier al langs gekomen. Wel bijblijven hè

De naam laat geen belletje rinkelen als zijnde het een applicatie, meer e.o.a. slang taal

[waterking]

Voordat je die machine compleet inricht, wil ik je de tip meegeven om te checken of de schrijfsnelheden van je nieuwe raid5/6 config wel in orde zijn. De leessnelheden zijn top, maar de schrijfsnelheden blijven in veel gevallen met een factor 8 achter op bijvoorbeeld een raid10 config.

Leuke software om een keer een test mee te draaien is CrystalDiskMark. Geeft duidelijke cijfers over de performance van je machine. Als de cijfers raar overkomen, draai dan ook even atto. Geeft namelijk ook duidelijkheid over de performance van je configuratie.

[Mafketel]

Grolsch schreef op woensdag 15 september 2010 @ 08:13:
en daarbij, kan bij het falen van 2 schijven ook een RAID10 set al z'n data kwijt zijn.
Dan zou ik ook liever voor een RAID5 gaan.

Ik ben het hier echt niet mee eens.
bij het falen van 2 schijven in een raid10 is het systeem misschien niet meer functioneel, bij raid 5 zeker niet meer en bij raid6 bij 3 uitgevallen schijven.

Bij het uitvallen van meer schijven dan waar een raid tegen kan, mag er nog steeds geen data verloren gaan buiten de meest recente die nog niet op de backup stonden. Dit moet echt beter begrepen worden, raid is om grotere schijven te hebben dan die er fysiek zijn, raid is er om een systeem te laten doordraaien als er wat hardware uitvalt. En raid kan ook gebruikt worden om de performance te verhogen, maar bedenk wel dat er situaties zijn waarbij 1 enkele schijf zelfs sneller is dan een raid met dezelfde schijven, oftewel je moet er goed over nadenken wat je doet.

[TheBorg]

Over betrouwbaarheid gesproken, misschien kun je beter 8x 2TB nemen (12TB netto bij RAID6) dan 12x 1TB (10TB netto bij RAID6). Het is iets duurder* (250 Euro ofzo) maar je hebt wel 4 minder schijven die stuk kunnen gaan... Misschien kun je daardoor af met een goedkoper chassis/controller waardoor je die 250 weer terug pakt.

*) Als ik even snel kijk bij aanschaf bij compleet HP systeem zelfs goedkoper.

[ Voor 11% gewijzigd door TheBorg op 21-09-2010 21:58 ]

[_JGC_]

Waar je ook even op moet letten is de stripesize die je kiest, en vervolgens hoe je je partities daarop neerlegt. Net zoals bij SSDs zijn RAID-controllers gevoelig voor hoe je je partities neerlegt op het array. Ik heb het bij LSI MegaRAID controllers gezien (Dell PERC4, oudjes al), dat een sequential read test op /dev/sda en /dev/sda1 een wereld van verschil gaven, omdat /dev/sda1 niet op een stripe boundary begon. Bij random writes, en zeker met RAID6, wordt dat verschil alleen maar groter als je dat niet voorelkaar hebt.
Windows doet het alignen over het algemeen wel goed in recente versies, maar controleer het voor de zekerheid even, je zult niet de eerste zijn die zwaar tegenvallende performance heeft door zo'n knullig foutje.

[Ethirty]

Even een update van mijn kant, ik ben jullie niet vergeten

Na maanden van gesteggel is eindelijk de kogel door de kerk en staat de nieuwe hardware klaar om in gebruik genomen te gaan worden.

Ik heb een nieuwe DL360 G6 server met P812 controller en een MSA60 met 12x 1TB SAS MDL voor elkaar weten te krijgen.

De disks zijn in 1 array gezet met 2 logische disks van elk 4,5TB in R6. Leuk dat verschil tussen TiB en TB, was even vergeten dat me dat een hele TB kost met deze groottes

Heb de MSA eerst aan de nieuwe server gehangen om via 2008 R2 gelijk de partities aligned aan te maken. Makkelijker dan via 2003 en ik moest toch eerst de hele setup testen voor ik ging beginnen. Heb uiteindelijk toch gekozen voor de NTFS default van 4KB per cluster en een 256KB stripe. De stripe ben ik nog niet helemaal zeker van of die optimaal is, dat wordt pas meetbaar als eea aan de nieuwe server hangt, maar die kan ik later nog aanpassen.

De MSA hangt momenteel aan de oude server om de data over te pompen. Heb een script gemaakt met een berg robocopy commando's zodat ik het kopiëren kan stoppen tijdens de piekbelasting van de server. Gaat nu met een paar 100GB per dag, valt me niet eens tegen gezien de performance van de oude omgeving

Nog een paar TB te gaan. In de tussentijd kan ik de nieuwe server verder inrichten en tweaken. Heb ervoor gekozen de software gelijk met de nieuwste versie opnieuw in te richten ipv de config over te zetten. Zo neem ik geen verkeerde instellingen mee én ik wordt gedwongen diep in de materie te duiken. Het configureren van de software is namelijk niet echt simpel te noemen met het gebruik van xml, jsp, html, bat en java door elkaar

[PcDealer]

Feli! Wat heeft het alignen voor nut?

[SpamLame]

PcDealer schreef op zondag 31 oktober 2010 @ 08:59:
Feli! Wat heeft het alignen voor nut?

idd ik hoop dat de investering de benodigde performance oplevert.
Alignment heeft te maken met sector boundaries en mbr/partitie layout.
Je wilt dat je partitie start op op een boundary voor performance reden.
Hier een linkje van MS voor SQL, maar gaat voor alle IO intensieve taken op.
http://msdn.microsoft.com...d758814%28SQL.100%29.aspx

[Zwelgje]

PcDealer schreef op zondag 31 oktober 2010 @ 08:59:
Feli! Wat heeft het alignen voor nut?

Disk performance may be slower than expected when you use multiple disks in Windows Server 2003, in Windows XP, and in Windows 2000

performance! in een VM kan het je zo 20% performance kosten. overigens doet 2008 al default aan disk allignment bij de installatie itt 2003

[_JGC_]

Zonder goede alignment heb je met een beetje pech 100% extra overhead tov wat je al had. Als je bij RAID6 ineens 2 stripes moet schrijven vanwege slechte alignment ipv 1 stripe betekent dat data teruglezen van 2 stripes, dubbel parity berekenen over 2 stripes en vervolgens het terugschrijven van die 2 stripes. Bij lichte I/O ga je dat niet merken, maar bij veel random writes ga je dat behoorlijk merken.

[Ethirty]

Plaatjes zeggen soms het meest