• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

SATA oder SAS

bananenBrot

Well-Known Member
Themenstarter #1
Hi,
ich plane gerade einen kleinen Speicher-Server mit knapp 14 Platten in nem RAID 60.
Jetzt kommt man ja unweigerlich zu dem Punkt, an dem man sich für SATA oder SAS entscheiden muss.
Mir sind die technischen Unterschiede schon relativ klar (bei SAS kann ich die Platte an 2 Controller anschließen zb) aber was genau bringt das in einem "Mid-Range" Szenario?
Hot-Swap geht ja bei nem RAID Controller auch bei SATA und die 6 GBit/s machen die Festplatten eh nicht voll, daher bringen 12 GBit/s auch nicht viel.

Ist SAS eher was für Enterprise oder hab ich da praktische Vorteile für die o.g. Größenordnung übersehen?
Gruß
 

mr44er

moderater Moderator
Mitarbeiter
#2
Man sagt, dass SAS 'robuster' sein soll (weil SCSI-Nachfolger). In der Realität gibts bei der Haltbarkeit wohl keine Unterschiede, da hat jeder andere Erfahrungen.

was genau bringt das in einem "Mid-Range" Szenario?
Multipath und so. Das bringt z.B. Redundanz über 2 Server. Wenn einer ausfällt, macht der andere eben weiter und du brauchst nur die Hälfte an Platten.
Oder wenn du zwei Controller in einem wichtigen Server hast, verkraftet er den Ausfall eines Weges (Kabel gezupft/defekt, Controller gestorben, whatever).
Hot-Swap geht nicht nur bei Platten, sondern man könnte auch den defekten Controller (im Betrieb!) rausziehen und austauschen. PCI-E hat die Spezifikation.
Ich selber habe es noch nie gemacht, das hab ich mich nie getraut und es war auch nie nötig. ;)

daher bringen 12 GBit/s auch nicht viel
Naja...Zukunft und so. Lieber Luft nach oben.

Das andere wirklich wichtige Ding: wenn eine SATA-Platte im Pool kaputt geht/wasauchimmer nicht lesen/schreiben kann, dann versucht sie es eine laaaaange Zeit immer wieder. Das blockiert (kann, muss nicht) den ganzen Pool und somit den Server oder noch garstiger, es behindert ZFS bei der Arbeit - dem Schutz deiner Daten. Wenn die Platte es immer wieder an der gleichen Stelle versucht, dann kann ZFS nicht immer entscheiden, ob noch was von der Platte kommt, da sie eben nicht 'tot' ist.
Man hat bei neuen SATA-Platten versucht, dieses Phänomen mit 'TLER' (Zeitlimit) einzudämmen als NAS-Systeme in Mode kamen und das eben öfter auftrat, da SATA nicht für Verbünde gebaut wurde. Ist jetzt arg einfach formuliert, wenn du danach suchst, wirst du technisch besser informiert. ;)

Ist SAS eher was für Enterprise
SAS ist für den professionellen Anwender, der viele Daten hat und die Vorteile für sich haben möchte.

Also die Preisunterschiede sind ja auch lange nicht mehr pervers, daher rate ich: nimm SAS, wann immer (technisch) möglich. Gerade wenn du neu bauen willst.
 

mark05

Well-Known Member
#3
Hi
Verzichte auf eine Hardware raus Controller , einfach jbod und zfs

Bei 14 Platten wirst du sowieso keinen
Passenden SATA Controller finden.

Holger
 

bananenBrot

Well-Known Member
Themenstarter #4
Die LSI MegaRAID Dinger gibts doch für nen Appel und um mich in zfs einzulesen fehlt mir echt die Zeit. Klar, ich könnte FreeNAS nehmen aber wenn ich ehrlich bin findet man im Internet einfach im Moment noch (zu) viele Threads in denen es um Performanceprobleme und Optimierungen geht (siehe keine Zeit) und bei FreeNAS habe ich dann quasi auch ne Blackbox wie einen RAID Controller.
Das System ist ja auch nur Mittel zum Zweck, da hier die bisherigen Storages volllaufen und ich kurzfristig den Platz brauche

Das andere wirklich wichtige Ding: wenn eine SATA-Platte im Pool kaputt geht/wasauchimmer nicht lesen/schreiben kann, dann versucht sie es eine laaaaange Zeit immer wieder. Das blockiert (kann, muss nicht) den ganzen Pool und somit den Server oder noch garstiger, es behindert ZFS bei der Arbeit - dem Schutz deiner Daten. Wenn die Platte es immer wieder an der gleichen Stelle versucht, dann kann ZFS nicht immer entscheiden, ob noch was von der Platte kommt, da sie eben nicht 'tot' ist.
Das wäre bisher der einzige für diesen Fall merkliche Vorteil, aber den kann ich ja auch dadurch umgehen, dass ich regelmäßig die Platten durchscrubben lasse
 

mr44er

moderater Moderator
Mitarbeiter
#5
Verzichte auf eine Hardware raus Controller , einfach jbod und zfs
Ja, definitiv. Bloß nicht das Hardware-RAID nutzen. Ich meinte sowieso, dass der Controller auf IT-Mode geflasht gehört (für ZFS), damit der Controller 'doof' ist und nur durchreichen soll bzw. einfach nur Slots ermöglicht.

Die LSI MegaRAID Dinger gibts doch für nen Appel und um mich in zfs einzulesen fehlt mir echt die Zeit.
Achso...ich hab das so verstanden, dass du ZFS nutzen willst.

Das wäre bisher der einzige für diesen Fall merkliche Vorteil, aber den kann ich ja auch dadurch umgehen, dass ich regelmäßig die Platten durchscrubben lasse
Jein. Die kompakte Aussage ist, dass sobald nur eine Platte hängt, somit der ganze Pool blockiert. Egal, bei welcher Art Zugriff.
Da wurde viel optimiert und es muss nicht passieren, wie gesagt, aber die Problematik an sich existiert.

Das System ist ja auch nur Mittel zum Zweck, da hier die bisherigen Storages volllaufen und ich kurzfristig den Platz brauche
Achso...also wenn es echt nur um 'mal kurz viel Platz hinstellen' geht, dann reicht SATA natürlich und da ist auch die RAID-Methode (fast) egal, denn wenn Zeit fehlt, dann nimm' das, womit du dich auskennst.
 

mark05

Well-Known Member
#6
Hi

Als zfs und Performance Optimierungen ist alles bloedsinn , ich bekomme , fast unoptimiert, auf die max raten die mir 1 Gbit hergibt.

Den größten Fehler den ich gemacht habe , der Performance friss ist das Thema 4k Blocksite der Platten.

Und für 2 Befehle braucht man kein stundium , nur dass FreeBSD Handbuch

Holger
 

medV2

Well-Known Member
#7
Hi,

also zu SATA vs SAS: Kommt etwas drauf an, für was du das ganze verwenden willst. Die SAS Platten sind idr etwas schneller, vorallem bei Seek-Zeiten da sie auch schneller drehen. Was Fehlerhäufigkeit betrifft wird zumindest von den Herstellen behauptet das sie besser sind. SAS haben idr. 1Bit aus 10^15 oder 10^16 Readerror spezifiziert, SATA gibts auch mit 1 aus 10^14. Natürlich betrifft das alles nur "echte", teure SAS Platten, nicht Nearline SAS.

Zum anderen:
Wenn du nen Raidkontroller um 400+ Euro kaufst willst du aufjedenfall den Cache verwenden (sofern du die BBU mitkaufst), also mindens jede Platte einzeln als Raid-0. Aber wenn du alles den Controller machen lässt sollte auch nicht viel dagegen sprechen.
Worauf du aufpassen solltest, deine StripeWith sollte ein Vielfaches der Sektorsize*Datensektoren sein und die Blocksize im FS entweder die StripeWith ohne Rest teilen oder auch ein Vielfaches sein. Aber auch hier gilt, wenn das nur ein einfaches Datengrab wird sollte das keine allzugroße Rolle spielen.
Solltest du den 6er Teil von Raid 60 doch von ZFS übernehmen lassen (also Raidz2 auf lauter 2er Raid0 Paaren die der Controller bereitstellt) würdest du dir die Raid6-Checkläufe sparen, die der Raidcontroller periodisch macht (oder machen sollte, Adaptec ist das default alle XY Tage, LSI weiß ich nicht auswendig). Die Redundanz liegt dabei allerdings etwas ungünstiger. Bei uns im Betrieb arbeiten z.b. 2 Server mit so einem Setup.
Allgemein hast du bei Raid 60 das Problem, dass Seek-Zeiten nicht skalieren, im Gegenteil, du hast immer die Seekzeit der ungünstigsten Platte. Sollte dein Usecase also etwas mit ganz vielen Random-Reads zu tun haben auf jedenfall zu SAS greifen, bzw. wäre vielleicht ein andres RaidSetup besser..
 

bananenBrot

Well-Known Member
Themenstarter #8
Als zfs und Performance Optimierungen ist alles bloedsinn , ich bekomme , fast unoptimiert, auf die max raten die mir 1 Gbit hergibt.
Also ich wollte eigentlich meine 10 GBit voll machen... mit 1 GBit komme ich bei 100 TB nicht weit.

Wenn du nen Raidkontroller um 400+ Euro kaufst willst du aufjedenfall den Cache verwenden (sofern du die BBU mitkaufst), also mindens jede Platte einzeln als Raid-0. Aber wenn du alles den Controller machen lässt sollte auch nicht viel dagegen sprechen.
Ich hatte bisher immer die 9361 mit CacheVault und bin damit gut gefahren.

Worauf du aufpassen solltest, deine StripeWith sollte ein Vielfaches der Sektorsize*Datensektoren sein und die Blocksize im FS entweder die StripeWith ohne Rest teilen oder auch ein Vielfaches sein. Aber auch hier gilt, wenn das nur ein einfaches Datengrab wird sollte das keine allzugroße Rolle spielen.
Das ist ein guter Punkt, über die Stripe-Size hatte ich mir nie Gedanken gemacht - danke für den Hinweis!

Allgemein hast du bei Raid 60 das Problem, dass Seek-Zeiten nicht skalieren, im Gegenteil, du hast immer die Seekzeit der ungünstigsten Platte. Sollte dein Usecase also etwas mit ganz vielen Random-Reads zu tun haben auf jedenfall zu SAS greifen, bzw. wäre vielleicht ein andres RaidSetup besser..
Ich habe nicht viele Random-Reads - es werden hauptsächlich sequentiell Daten gelesen (immer so 2-3 TB am Stück). Eigentlich wäre da Raid 10 besser aber ich habe für die 100 TB nur knapp 10.000 Euro übrig