SATA blir raskere

[Anders Jensen]

Men hvor mye mener du IOPS vil variere med ellers like mange disker i en ren FC løsning og en kombinert SAS/FC?

I utgangspunktet ingenting skulle jeg mene.

 

Forøvrig enig i at 300GB SAS er flotte greier. Vi har for mye data og for lite penger så det går i 500GB og 1TB SATA disker. Skulle gjerne byttet til 300 eller 450 GB SAS, men med litt tweaking får vi ut nok ytelse av store SATA disker også. Ofte er det mye mer å hente på å jobbe smart heller enn å jobbe hardt, enten det er tweaking av hardware eller software. Blir f.eks litt oppgitt når jeg får beskjed om at systemene er for trege og så vet jeg at software gutta har 10x ++ ytelse å gå på hvis de bare gidder å prioritere det... klart de har masse features og stadig endrede algoritmer å forholde seg til så jeg skjønner skvisen deres også.

 

På den andre siden har vi økt reell regnekraft med nesten 100x og det spøker for en 10x i dataproduksjon.. så vi må nok gjøre noe snart med lagringen.

Endret 12. mars 2009 av Anders Jensen

[Theo343]

Enig der AJ. Våre 300GB SAS disker brukes også kun til høyprioritert innhold ift. ESX VMer. Men godt å høre at vi valgte en god løsning på tross av det alle "ekspertene" mente og som anbefalte FC hele veien.

Endret 12. mars 2009 av Theo343

[Anders Jensen]

Enig der AJ. Våre 300GB SAS disker brukes også kun til høyprioritert innhold ift. ESX VMer.

Kjører VM mot 15rpm 146GB FC i RAID 10. Her er det kun IOPS som teller. Skal bli utrolig bra når SSD blir modent for dette til spiselig pris. Å betale en kvart mill, eller deromkring, for 1TB brukbar plass er ikke veldig fristende i disse finanskrise tider.

[Theo343]

Ja jeg gleder meg også stort til vi kommer dit AJ, det blir en enorm overgang.

[leifeinar]

Er det ikke bedre at vi begynner og disker som monteres i pci eller pci-e portene? med tanke på hastigheter og kabelrot??

[Theo343]

Eller onboard SSDer som er direkte koblet til PCIe bussen via SB el. Det vil hjelpe på å få ned størrelsen på HTPC og NMT type maskiner.

 

Ellers på tradisjonelle stasjonære maskiner synes jeg fortsatt brønnene er det beste fysisk plassområdet å utnytte for lagringsmedia, men at "break out" kort sitter i PCIe spor med så enkle signalkabler som mulig.

Husk at ATX har begrenset sporplass og det er ofte en del andre behov man har i dem.

 

På servere derimot med E-ATX kort i 19" rackbokser og mulighet for mange spor og mindre behov for andre enheter i dem er rene PCIe enheter ideelt.

Endret 12. mars 2009 av Theo343

[Anders Jensen]

Er det ikke bedre at vi begynner og disker som monteres i pci eller pci-e portene? med tanke på hastigheter og kabelrot??

 

Hva mener du med kabelrot? Jeg har en server med ca 90 disker tilkoblet og det er 4 kabler fra RAID kontrollerne. Dette er helt standard direct attached storage (DAS) ikke noe SAN inn i bildet.

 

Når det gjelder hastighet så vil selvfølgelig ekstra avstand alltid være negativt, men vi er ikke i nærheten av SSD med så heftige specs at avstand er en nevneverdig komponent i dag. Med tid og stunder vil avstand bli en utfordring. Den tid, den sorg.

 

Edit: med SAS 8087(intern) og 8088 (ekstern) kabler så får du 12Gbps per kabel og du kan gjerne koble opp flere hundre disker per kabel, avhengig av RAID kontrolleren (240 er det meste jeg har sett på LSI kontrollere). Dette krever selvfølgelig port expandere og de kommer gjerne sammen med backplane i diskhyllene så det er minimalt med kabling.

 

Sjekk ut disse systemene:

 

RAID kontrollere:

http://h18004.www1.hp.com/products/servers...lers/index.html

Diskhyller:

http://h18006.www1.hp.com/storage/disk_sto...ures/index.html

Endret 12. mars 2009 av Anders Jensen

[Theo343]

Rene diskbokser/hyller med SCSI eller SAS er kjekt, men SAN er bedre når man skal ha mange servere direkte tilkoblet samme lagring.

[leifeinar]

Eller onboard SSDer som er direkte koblet til PCIe bussen via SB el. Det vil hjelpe på å få ned størrelsen på HTPC og NMT type maskiner.

 

ja, det hadde vært helt fantastisk i alle maskiner. 64 gig lynrask OS-disk integrert i hovedkort på en lur måte

 

Hva mener du med kabelrot?

 

 

ikke rot, men en komponent mindre og 2 kabler mindre, ihvertfal hos meg

[GullLars]

Jeg har en kommentar til server adminsa her. Forestill dere:

Ytelsen fra ioDriveDue i pris pr GB og kapasiteten til (OCZ) Z-Drive.

Begynner siklet å renne ved tanken?

1TB PCIe SSD med 200k/130k IOPS og 1,5/1,4 GB/s båndbredde til $1500-$2000...

*homer simpson drool*

(Dette kan realistisk være tilgjengelig innen 1-1,5 år hvis konkurransen tar seg opp i segmentet. Fusionio har planer for ioDriveDuo 1,2TB etter sommeren, men til mye høyere pris )

[Anders Jensen]

Jeg har en kommentar til server adminsa her. Forestill dere:

Ytelsen fra ioDriveDue i pris pr GB og kapasiteten til (OCZ) Z-Drive.

Begynner siklet å renne ved tanken?

1TB PCIe SSD med 200k/130k IOPS og 1,5/1,4 GB/s båndbredde til $1500-$2000...

*homer simpson drool*

(Dette kan realistisk være tilgjengelig innen 1-1,5 år hvis konkurransen tar seg opp i segmentet. Fusionio har planer for ioDriveDuo 1,2TB etter sommeren, men til mye høyere pris )

HP leverer dette i dag til blades med rating på 100k IOPS. De har modeller fra 80GB til 320GB i mezzanine format (liten sokkel med PCIe signalering). Koster fra $4400 for 80GB til $13200 for 320GB. Jeg har veldig vanskelig for å se for meg hvilken workload som skulle rettferdiggjøre dette.

http://h18006.www1.hp.com/products/storage...ator/index.html

 

Hva slags datasett har behov for å bli lest eller skrevet hvert femte minutt? Eneste jeg kan komme på er at dette er genialt til OpenSolaris sin hybrid storage pool. Alt annet kan løses billigere med samme throughput og mye større kapasitet. Saken er jo at hvis du faktisk kan nyttegjøre så stor ytelse så har du også hundrevis av TB med data eller en algoritme som suger lut og da er løsningen å programmere på nytt.

 

Hvis du faktisk har hundrevis av TB med data så har du også hundrevis av spindler og kontrollere med stor DRAM cache og 500k IOPS er ikke mye for en moderne lagringskontroller til SAN. Den tidligere nevnte AMS2500 takler 900k, men det er klart du skal ha et interessant oppsett for å holde noe i nærheten av det kontinuerlig i skriving, men med 32GB cache kan du holde på en god stund.

Endret 13. mars 2009 av Anders Jensen

[GullLars]

Når du snakker om 500k IOPS fra snurredisker, så neglisjerer du totalt hva accesstime gjør for applikasjonene. Det er MASSIV forskjell på IOPS ved 0,05ms og 5,2ms. Disse kortene passer fint inn som tier-0 der RAM blir for dyrt eller uprakisk.

ioDrive har for eksempel blitt brukt med stor suksess i transaksjonsservere, og passer fint til databaser, eller et hurtiglager i OpenSolaris som du sier.

Formålet for ioDrive blir alså enten en IOPS akselerator. Den passer godt der det ikke trengs mange TB kapasitet, men accesstime og IOPS er kritisk.

 

$/IOPS, W/IOPS, og $/GB er det en god konkurrent for RAM som tier-0

[Anders Jensen]

Jeg håper, akkurat som Simen1 og flere andre her, at PCIe vil bli standard for SSD i løpet av året (men selvfølgelig er det fint om det kommer SATA/IDE utgaver for å speede opp gamle maskiner også).

Bare ta det med ro, det kommer! Forsinkelse er det største og vanskeligste problemet å håndtere i datamaskiner (bundet av elektriske signaler sin hastighet som igjen er bundet av lysets hastighet), og derfor har og vil industrien alltid miniatyrisere og integrere. Om 10 år har vi antagelig RAM integrert på CPU og vi har integrerte SSD kontrollere på CPU med non-volatile minne i form av DIMM eller lignende. Det er mine 0,50 NOK.

 

Edit: når jeg sier om 10 år så har vi "this and that" så sikter jeg til maskiner av typen PC ol. For embeded markedet er allerede non-volatile minne integrert sammen med CPU for lengst.

Da var vel fremtiden for SSD i DIMM lignende format i boks.

http://www.digi.no/807892/foreslaar-aapen-...-for-flashminne

[Simen1]

Det virker lovende! Veldig bra initiativ fra Sun

[Theo343]

Blir det ikke feil å kalle det "Open Flash Module" når det er SO-DIMM basert?

[Simen1]

bygger på en JEDEC formfaktor som tilsvarer en minnemodul av typen SO-DIMM.

Formfaktoren er basert på SODIMM, mens signaleringen, spenninger og key vil nok være egne for OFM.