Fibre Channel Festplatten

[holger0910]

Welche Vorteile hat es, wenn ein in einem SAN Fibrechannel-Festplatten verwendet werden im Vergleich zu SAS oder SCA-Festplatten?

[Ebbi]

Weil jede Umsetzung des Übertragungsprotokolls eine mögliche Fehler- und Verlustquelle darstellt.

[holger0910]

Verstehe ich grundsätzlich. Jedoch addressiert der ans SAN angeschlossene Server doch nicht die Festplatte, sondern den Controller des Storage-Systems (inkl. Raid/Mirror-Logik), und der wiederum spricht die Festplatte an.
Ich frage mich, ob aktuelle Platten die FC-Bandbreite voll ausnutzen können...

Wenn ich es recht verstehe sind FC-Platten "state of the art"...?

[karakal]

Wenn ich es recht verstehe sind FC-Platten "state of the art"...?

Ist die Frage, was du unter "state of the art" verstehst?

[truerasp]

Verstehe ich grundsätzlich. Jedoch addressiert der ans SAN angeschlossene Server doch nicht die Festplatte, sondern den Controller des Storage-Systems (inkl. Raid/Mirror-Logik), und der wiederum spricht die Festplatte an.
Ich frage mich, ob aktuelle Platten die FC-Bandbreite voll ausnutzen können...

Wenn ich es recht verstehe sind FC-Platten "state of the art"...?

noch so ein holy war ich sehe das so (und ich verbau grad tonnenweise das zeug) dass man mit SAS auf jedenfall servernah stressfreier faehrt. aber zur eigentlichen frage:

fc platten stehen ja ohnehin nur in einem irgendwie gearteten array zur diskussion.

da gibts erstens die jbods, einfache plattenstapel die am server haengen. wenn ich ein fc-jobod habe dass ich mit fc anfahre kann ich intern nicht umsetzen. wenn ich ein sas oder scsi jbod habe muss ich das ebenfalls mit dem controlelr anfahren.

habe ich ein intelligentes storage array das ich mit scsi fahre stellt sich die frage imho auch nicht.

bleibt ein array das ich extern mit fc anfahre und das intern irgendwie weiter verteilen muss. das haengt dann wieder vom controller ab, inwieweit ich hier tatsaechlich umsetzen oder skalieren (und damit geld ausgeben) moechte.

wenn ich intern scsi controller verwende um die disk shelfs anzufahren kann ich pro scsi connection 14 platten adressieren. bei ner recht typischen config von 4 internen bussen (controller chips) komme ich damit auf 56 platten. (15 IDs - 1 Controller) bei redundanten auslegungen habe ich meistens das selbe gerade nochmal oder muss die chips sogar aufteilen.  (z.b. hp msa 1500 hat maximal 56 platten)

bei FC zur internen verdrahtung kann ich  im internen FC loop des arrays pro chip (internen controller kanal) 256 ids vergeben und irgendwie je nach controllern 240 oder so platten pro fc loop verbauen.  wenn ich mehrere interne loops habe werden das entsprechend mehr. fuer den ersten fall hat man bei einer eva 8000 von hp hat man zwei interne loops die aber voll redundant aufgebaut sind und damit identische adressierungen fahren (dafuer gibts diesen kontrollbus) und damit kriegt man in der 2c18d konfig diese maximale bestueckung von 236 platten (256 - 18 shelf IDs - 2 controller IDs)

der primaere grund hierfuer ist die skalierung auf diese anzahl von platten, unter verwendung von standartisierten vergleisweise guenstigen komponenten (fc jbods) und nicht zwangslaeufig die protokollumsetzung.

bei noch groesseren arrays die mehrere interne busse fahren (hp XP ... ) redet man intern sogar von "chips" fuer die kanaele und da wird die entscheidung haeufig anhand der benoetigten netto datentransferraten getroffen. es gibt/gab dieverse XP versionen die aus diesen gruenden trotz mehrerer hundert platten sehr viele interne scsi busse gefahren sind.

gruessle frank

imho sind fc platten damit nicht state of the art sondern einfach da. sas waere "state of the art" weil neu und toll

ergaenzend: in der eva 2c18d kriegt man theoretisch 252 platten gesteckt aber es gibt nen support guide in dem drin steht welche positionen nicht bestueckt werden duerfen weil danach loopadressen doppelt vergeben werden wuerden. da die adressen shelfweise vergeben werden ist das n recht wichtiger input, zumal bei hp schon mal n falsch bestuecktes system das werk verlaesst. 

[stiefkind]

Welche Vorteile hat es, wenn ein in einem SAN Fibrechannel-Festplatten verwendet werden im Vergleich zu SAS oder SCA-Festplatten?

SCA steht ja erstmal für Single Connector Attached. Und heisst im Klartext, dass über einen einzigen Stecker Daten und Strom kommen. Zwingende Voraussetzung für Hotplug-Platten, wie sie ab Mitte der 90er Jahre des letzten Jahrhunderts eingeführt wurden und mittlerweile flächendeckend benutzt werden.

SAS und FC sind vom Plattenaufbau (auch mechanisch) gleich. FC als Protokoll ist eigentlich auch nichts anderes als serialisiertes SCSI. Das selbe, was auch SAS macht. FC gibt es auch über Kupfer, die Platte selbst innerhalb des Storage macht das zB. Hat also relativ wenig mit Fiber als Übertragungsmedium zu tun.

Wesentlicher Unterschied dürfte allerdings sein (ich kenne SAS noch nicht so intim): FC-Platten sind normalerweise dual-ported angeschlossen. Heisst: sie haben zwei Ports und auch zwei Verbindungen in das Storage-System. Üblicherweise sind das redundante Loops. Ebenfalls üblicherweise (wenigstens bei bezahlbarem Midrange-Storage) hängt jeweils eine Loop an einem Controller, wobei das Controller-Pärchen im Storage meistens redundant ist.

In der Praxis heisst das: Wenn der Server einen Multipathing-Treiber nutzt, der mit dem Storage klar kommt und der sowas wie Load Balancing macht, kannst du eine FC-Platte immer über beide Controller ansprechen. Im einfachsten (und häufigsten) Fall ist das ein Round-Robin-Verfahren.

Command Queuing machen SAS und FC gleichermaßen. Warum macht man das? Plattenkommandos werden in eine Queue gepackt, von der Controllerfirmware (Plattencontroller, nicht RAID-Controller!) dann so umsortiert, dass der Kopf möglichst wenig Bewegungen machen muss. Im Idealfall fährt der Kopf bei jedem Queue-Run genau einmal über die Oberfläche.

Jetzt kann man einwenden, dass der Server ja eigentlich mit dem RAID-Controller spricht, also i. d. R. mit dem Cache da drin. RAM. Schnell. Ja, aber: wenn man Wert drauf legt, dass die Daten auch wirlich und richtig auf Platte stehen, schaltet man den Cache auf write through. Das Betriebssystem kriegt das Commit also erst zurück, wenn die Daten wirklich auf Platte stehen und nicht nur im Cache. Von Platte lesen ist was ganz anderes

Wenn man SAS/FC mit SATA vergleicht, kommt noch eine wichtige Größe ins Spiel: Bandbreite ist nämlich mitunter nicht alles. Bei großen sequential I/O ist SATA etwa gleichauf mit FC/SAS. FC/SAS punktet ein bisschen höher, was im wesentlichen auf die größere Umdrehungsgeschwindigkeit zurück zu führen ist. Kommen halt in der gleichen Zeit ein paar Sektoren mehr am Kopf vorbei.

Was aber häufig wenig oder gar nicht beachtet wird, sind die IOPS. Also die Anzahl der I/O Operationen pro Sekunde. Die sind dann wichtig, wenn man -- typischerweise in Datenbank-Umgebungen -- sehr viele kleine Blocks random über die Platte lesen und schreiben will. Übliche Blockgrößen sind dabei 4kB oder 8kB (hängt vom Datenbanksystem und vom Filesystem ab, wenn ein Filesystem verwendet wird). Aktuelles Midrange-Storage (Sun ST6140/ST6540, IBM DS4000, EMC CX, sicher gibt es auch was von HP, da kenne ich nur nichts) erreicht da mit FC auf dem Papier Werte zwischen 10.000 und 80.000 IOPS. Das ist ein Vielfaches von SATA. Auch hier wieder: FC und SAS schenken sich da nicht sonderlich viel. Der Wert ist abhängig von der Konfiguration des darunterliegenden RAIDs. Hersteller messen normalerweise ein RAID-0 mit einer sehr großen Anzahl Platten (also sehr viele Spindeln). Engpass ist bei solchen Messungen i. d. R. tatsächlich der RAID-Controller (also das Memory und die CPU, die das Protokoll-Handling macht) und nicht die Platten. Dafür sorgen die Hersteller bei der Messung schon.

Wer tiefer in die Performance-Messung von Plattensystemen abtauchen will, sei auf das Storage Performance Council verwiesen: http://www.storageperformance.org/. Das ist sowas ähnliches wie SPEC, aber halt für Storage Systeme.

Und für alle die, die der Meinung sind, FC/SAS-Platten seien stabiler und langlebiger als SATA, habe ich noch zwei PDFs parat:

Failure Trends in a Large Disk Drive Population.
Eduardo Pinheiro, Wolf-Dietrich Weber and Luiz Andre Barroso, Google Inc.
http://research.google.com/archive/disk_failures.pdf

Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?
Bianca Schroeder, Garth A. Gibson, Computer Science Department Carnegie Mellon University
http://www.cs.cmu.edu/~bianca/fast07.pdf

Beides Papers von der FAST'07 (5th USENIX Conference on File and Storage Technologies). Viel Spass bei der Lektüre 


wolfgang

[holger0910]

Uff....
Dankeschön für die vielen Info's.
Das FC-Festplatten nichts mit Glasfaser zu tun haben, wusste ich nicht.

Eine Frage noch im Anschluss:
Hat jemand Erfahrungen mit dem Hitachi TagmaStore AMS200 ?

[truerasp]

Hat jemand Erfahrungen mit dem Hitachi TagmaStore AMS200 ?

haengt von der art der erfahrung ab ich hab schon ne menge luns von den kisten im san sehen und einbinden muessen.

[stiefkind]

Eine Frage noch im Anschluss:
Hat jemand Erfahrungen mit dem Hitachi TagmaStore AMS200 ?

Wie trurasp schon sagt: Was genau willst oder musst du wissen?

Ich kenne die Tagmas teilweise. Nicht nur freigegebene LUNs im SAN.
SATA auf HDS ist generell keine gute Idee. Wenigstens war es das vor einem Jahr noch nicht und ich glaube nicht, dass sich da zwischenzeitlich nennenswert was geändert hat. Problem dabei: Um sicher zu gehen, dass auf den Platten kein Müll steht, macht der Controller nach dem Read noch ein Verify. Das kann man nicht ausschalten, das macht der halt bei SAS-Platten einfach. Sind dann nochmal ein paar I/Os mehr je Schreibzugriff, was sich natürlich negativ auf die Performance auswirkt.

Mit FC-Platten ist die Maschine schick schnell.

Wenn man hinter einer ASM anderen Storage virtualisiert, muss man höllisch auf Caches aufpassen. Sonst bremsen sich die gegenseitig aus. Details kriege ich um diese Uhrzeit nicht mehr zusammen, das Problem ist nicht trivial. Wir haben das an einer Kunden-Anlage erlebt und weil wir's nicht glauben wollten, haben wir das im Hitachi-Labor in Dreieich nachgestellt und nachgemessen. Danach glaubten wir.

wolfgang

[dominik_bsl]

Ich kenne die Tagmas teilweise. Nicht nur freigegebene LUNs im SAN.
SATA auf HDS ist generell keine gute Idee. Wenigstens war es das vor einem Jahr noch nicht und ich glaube nicht, dass sich da zwischenzeitlich nennenswert was geändert hat. Problem dabei: Um sicher zu gehen, dass auf den Platten kein Müll steht, macht der Controller nach dem Read noch ein Verify. Das kann man nicht ausschalten, das macht der halt bei SAS-Platten einfach. Sind dann nochmal ein paar I/Os mehr je Schreibzugriff, was sich natürlich negativ auf die Performance auswirkt.

Das höre ich ungern. Wir überlegen uns gerade, eine AMS500 zuzulegen. Primär zwar mit FC Disks aber für den Legacy-/Archivbereich wären SATA Disks vorgesehen gewesen.

Mit FC-Platten ist die Maschine schick schnell.

Wenigstens etwas


Gruss
Dominik

[stiefkind]

Ich kenne die Tagmas teilweise. Nicht nur freigegebene LUNs im SAN.
SATA auf HDS ist generell keine gute Idee. Wenigstens war es das vor einem Jahr noch nicht und ich glaube nicht, dass sich da zwischenzeitlich nennenswert was geändert hat. Problem dabei: Um sicher zu gehen, dass auf den Platten kein Müll steht, macht der Controller nach dem Read noch ein Verify. Das kann man nicht ausschalten, das macht der halt bei SAS-Platten einfach. Sind dann nochmal ein paar I/Os mehr je Schreibzugriff, was sich natürlich negativ auf die Performance auswirkt.

Das höre ich ungern. Wir überlegen uns gerade, eine AMS500 zuzulegen. Primär zwar mit FC Disks aber für den Legacy-/Archivbereich wären SATA Disks vorgesehen gewesen.

Kommt halt auch drauf an, was man auf die SATAs ablegen will und was man davon erwartet. Funktionieren tut das schon. Auch sehr stabil und zuverlässig. Aber nennenswert mehr als ca. 30MB/s write auf ein RAID-5 darf man halt nicht erwarten. Wenn ihr da jetzt überwiegend große sequential I/Os habt oder -- noch besser -- deutlich mehr lest als schreibt, ist das ja wieder was anderes. Wir hatten die Platten als Plattencache für ein HSM-System, wo nachts auch Backup-Container rein geschrieben wurden (backup to disk) und diese Container dann auf den Ausfallstandort geclont werden sollten. Backup ging noch gerade so, Cloning war quasi nicht machbar. Kann man sich ja mal ausrechnen, wenn da deutlich dreistellige Gigabytes auf 30MB/s runter geschrieben werden sollen.

Ist mitunter auch eine Preisfrage. Für das, was der Storage kostet, kann er zu wenig. Wenn ihr jetzt alles einheitlich unter einem Dach haben wollt (selbes Management-GUI, ein Wartungspartner etc.) sind das ja Entscheidungen, die nicht von nackter Technik getrieben sind. Eine AMS hat ja auch noch ein paar andere Features, die man woanders womöglich nicht so schnell oder gar nicht kriegt, dafür zahlt man da aber auch entsprechend Lizenzen. SATA-Storage kann man allerdings deutlich billiger und auch eine gute Ecke schneller kriegen

wolfgang

[dominik_bsl]

stiefkind:

Danke für Dein Posting. Alternativ steht bei uns ein Sun STK-6140 Array zur Debatte. Wir haben schon solch ein Teil mit 500GB SATA Disks und schreiben auf ein 5 Disk RAID5 locker gut über 100MB/s (Veritas NBU Backup to Disk).

Zwei HDS 9985 (NSC-55) haben wir auch noch, so gesehen ist es mir die Frage nach dem Management-GUI egal: Ich kenne eh beide

Gruss
Dominik

[stiefkind]

Zwei HDS 9985 (NSC-55) haben wir auch noch, so gesehen ist es mir die Frage nach dem Management-GUI egal: Ich kenne eh beide

Nutzt ihr an dem ST6140 den mitgelieferten CAM (Common Array Manager, das webbased Teil) oder das "richtige" Java-GUI, das z. B. IBM mit den Geräten ausliefert? Bei IBM ist das übriges die DS4000-Reihe, konkret ein DS4700. Und original kommt das alles weder von IBM noch von Sun, sondern von LSI Logic bzw. Engenio. Letzteres war früher mal die Storage Division von LSI, war dann mal als Tochterunternehmen selbständig und ist jetzt wieder die Storage Division von LSI

Das GUI heißt bei IBM Storage Manager und bei LSI Santricity. Selten ein so intuitiv zu bedienendes GUI für Storage Management gesehen. Leider tut das IBM-Tool nicht mit Sun-Storage. Früher konnte man da mal beim Java-Aufruf ein paar passende Register setzen, mittlerweile ist auch das unterbunden.

Die 6140 macht weniger Heckmeck beim Schreiben auf SATA bzw. behandelt SATA identisch wie FC, das wirkt sich dann doch ein bisschen auf die Performance aus. Man kann innerhalb eines Disk-Shelfs sogar FC und SATA mischen. SATA-Platten haben dazu hinten einen Bus-Umsetzer, der kann 3Gbit/s, FC-Platten können in den Maschinen ja mittlerweile 4Gbit/s (wenn man ein aktuelles Gerät hat). Das mit dem Mischbetrieb geht gut, haben wir bei einigen Kunden stehen.

Hitachi macht allerdings schon immer ihr eigenes Ding

wolfgang

[dominik_bsl]

Nutzt ihr an dem ST6140 den mitgelieferten CAM (Common Array Manager, das webbased Teil) oder das "richtige" Java-GUI, das z. B. IBM mit den Geräten ausliefert? Bei IBM ist das übriges die DS4000-Reihe, konkret ein DS4700. Und original kommt das alles weder von IBM noch von Sun, sondern von LSI Logic bzw. Engenio. Letzteres war früher mal die Storage Division von LSI, war dann mal als Tochterunternehmen selbständig und ist jetzt wieder die Storage Division von LSI

Wir benutzen den CAM. Santricitiy ist offiziell nur unter Windows supported und Windows läuft zum Glück nicht auf meiner Ultra45 Workstation hier Bin aber mit dem CAM insofern zufrieden als dass ich eh nur die Basisfunktionen des Arrays nutze und für das Bereitstellen von Volumes und ein bisschen LUN Mapping tut es gut genug.

Ich weiss, dass die Dinger nicht von Sun selber kommen. Sun hat AFAIK fast alle jemals angebotenen Storage Arrays extern eingekauft. Im Fall der 6140 war das eine gute Sache, bei dem T3-Schrott oder meinem Lieblingshassobjekt 3510FC (Krüppel-GUI) eine eher ungünstige Wahl. War 7 Jahre Sunnie und habe den meisten von den Geräten gearbeitet :-)

Gruss
Dominik

[stiefkind]

Wir benutzen den CAM. Santricitiy ist offiziell nur unter Windows supported und Windows läuft zum Glück nicht auf meiner Ultra45 Workstation hier

Tut auch prima unter Linux.
Das nur am Rande.

Ich weiss, dass die Dinger nicht von Sun selber kommen. Sun hat AFAIK fast alle jemals angebotenen Storage Arrays extern eingekauft. Im Fall der 6140 war das eine gute Sache, bei dem T3-Schrott oder meinem Lieblingshassobjekt 3510FC (Krüppel-GUI) eine eher ungünstige Wahl.

Och, das ASCII-Interface über Telnet ist schon so halbwegs brauchbar. Das CLI einer T3/T4 finde ich da sehr viel übler und unübersichtlicher.

wolfgang, seit ziemlich genau 10 Jahren im Sun-Geschäft...