Diskussion:Storage Area Network

Definition eines SAN

Die Einleitung des Artikel ist für mich soweit OK, wenn auch fern von optimal. Was mir dann fehlt ist, was bewirkte die Entwicklung von SAN und welche Probleme sollen damit gelöst werden? Dazu gehöhrt in der Einleitung (nach der Definition eines SAN) eine Gegenüberstellung der Vor- und Nachteile. Was sind die Ziele eines SANs? -- Oceco 00:13, 18. Dez. 2009 (CET)

Strukturierung

Nicht nur im Artikel sondern auch hier auf der Diskussionsseite ist eine Restrukturierung überfällig. Werde dies hoffentlich mal anpacken können, ohne etwas zu löschen. Dabei möchte ich mich von folgenden Überlegungen leiten lassen:

• Vor SAN gab es DAS
• Meiner Meinung nach war DEC die erste Firma, welche shared Storage im Rahmen ihres VMSclusters mit den HSC50 realisierte
• Auf DAS folgte NAS
• Weil auch NAS nicht alle Anforderungen der Anwender erfüllte, entstand SAN (mal abgesehen von ESCON)

Danach sollte eine Gegenüberstellung von DAS/NAS/SAN stattfinden (in einem ausgelagerten Artikel).

• Neu gesellt sich noch Cloud dazu

Wie das im Detail ausehen soll, weiss ich noch nicht. Wenn ich mir aber das Chaos und die Falschinformationen (auch in der en-Wikipedia) anschaue, so besteht hier Handlungsbedarf!

Die Strukturierung übertrifft den Bereich von SANs. Koordination ist vonnöten. Ich hab aber keine Ahnung davon, wie man das in Wikipedia sauber in die Wege leitet. Ich werde dies deshalb mal aus meinem POV schildern in der Hoffnung auf konstruktiven, erläuterden Feedback -- Oceco 00:13, 18. Dez. 2009 (CET)

Bandbreite?

Hallo, was ich in diesem Artikel nicht verstehe ist folgender Satz: "Sie arbeiten heute mit Bandbreiten im Bereich von 1 GBit/sec bis 2 GBit/sec. Da sie ein spezielles, an die Anforderung von Massenspeichernutzung angepaßtes Protokoll verwenden, sind Übertragungsraten von theoretisch 400 MB/sec möglich."

Dabei widersprechen sich für mich die 1 GBit/sec vs. 400 MB/sec.

Kann das mal jemand anders formulieren, damit man versteht was gemeint ist? Ansonsten ist alles ganz ok und ich würd mich sogar freuen wenn es noch mehr zu schreiben gibt zb wie man das im Einzelnen einbinden kann.

Gemeint ist folgendes, die maximalen Übertragungsraten beziehen sich auf aggregierte Schreib-/Lese-Zugriffe. Geht man von einer 2 GBit FibreChannel-Verbindung im Point-to-Point-Betrieb aus, so können full-duplex 4 GBit Daten übertragen werden. 4 GBit entspricht 512 MByte. Hier handelt es sich jedoch noch immer um eine theoretische Übertragungsrate. Man geht in einer switched fabric von einem durchschnittlichen Protokoll-Overhead zwischen 10% bis maximal 20% aus, also ein weitaus geringerer Overhead als z.B. im Ethernet. Zieht man nun diesen Protkoll-Overhead ab, so bleiben bei einer 2 GBit FibreChannel Verbindung ca. 400 MegaByte wirkliche Nutzdaten pro Sekunde übrig. -- Raven 19:21, 27. Okt 2004 (CEST)

In einem typischen SAN werden alle Komponenten redundant gehalten, d.h. zwischen Server und Disk-Array hat man z.B. 2 FC-Leitungen, also 2 x 2Gb/s. Beide Leitungen werden parallel genutz ergibt 4 Gb/s. Die Übertragungsleistung wird in bit/sec angegeben, da es sich um eine serielle Übertragung handelt. Durch den Leitungscode 8B10B-Code werden 8 Bit Daten mit 10 Bit kodiert: 4Gb/s : 10 bit/Byte -> 400MB/s. Das ist inklusive FC-Protokoll-Overhead, der aber sehr viel geringer als wie bei TCP/IP ist. Für die Nutzdaten verbleiben letztlich ca. 350MB/s.

BTW: Heute kann man Verbindungen schon mit 4, 8 oder 10Gb/s betreiben. -- Oceco 05:31, 19. Sep. 2009 (CEST)

Mittlerweile steht zu lesen: "Sie arbeiten heute mit Übertragungsraten von bis zu 16 GBit/s. Da sie ein spezielles, an die Anforderung der Massenspeichernutzung angepasstes Protokoll verwenden, sind Übertragungsraten von theoretisch 1,6 GB/s möglich". Das ist sehr verwirrend, da dasselbe Maß mit zwei verschiedenen Maßeinheiten verwendet wird. Welche ist denn nun gebräuchlicher? GB/s or GBit/s? --ComradeMicha 09:40, 27. Jan. 2010 (CET)

Ich schließe mich an. Das ist sehr suboptimal, selbst für allgemeine IT-Experten, als den ich mich bezeichnen möchte.-- WernerPopken 13:08, 19. Jun. 2010 (CEST)

Da es sich um eine serielle Datenübertragung handelt wird die Geschwindigkeit (von Profis) mit Gbit/s angegeben, da die bits hintereinander durch die Leitung gejagt werden, wie auch bei Ethernet. Da aber Disks ursprünglich stets einen parallelen Bus (IDE, ATA, SCSI) hatten, wollen es viele noch immer in Bytes/Sekunde wissen. Die Übertragung ist wie beim Morsecode, da werden die Signale "lang" resp. "kurz" auch seriell übertragen. Man kann natürlich versuchen, dies in Zeichen pro Sekunde umzurechnen, ob das sinnvoll ist, lasse ich mal dahingestellt. -- Oceco 03:13, 20. Jun. 2010 (CEST)

Die Aussage ist zudem ein Widerspruch in sich: 16GBit/s = 2GByte/s, da 8 Bit einem Byte entsprechen. Wie kann dann mit Übertragungsraten von 2GByte/s gearbeitet werden, wenn theoretisch nur Übertragungsraten bis zu 1,6GByte/s möglich sind? Korregiert mich, falls ich einen Denkfehler habe (nicht signierter Beitrag von 80.187.100.196 (Diskussion) 17:08, 23. Nov. 2014 (CET))

Fibrechannel verwendet auf der Leitung eine 8B/10B-Kodierung, d.h. aus 8 Bit Nutzdaten werden 10 Bit auf der Leitung. Dies ist notwendig um auf Kupferkabeln keine störenden Gleichspannungsanteile zu erzeugen. Daher hast Du bei einer Datenrate von 16 GBit pro Sekunde effektiv nur 1,6 GByte pro Sekunde an Nutzkapazität. --Taxi1729 (Diskussion) 17:55, 23. Nov. 2014 (CET)

open source bzw. kostenlos

Gibt es auch kostenlose storage area network lösungen, mit denen man auch sein eigenes zuhause aufbauen kann... z.B. für linux? --Abdull 14:06, 11. Mär 2005 (CET)

Dazu kannst du iSCSI verwenden, was leider in dem Artikel bis dato keinerlei Erwähnung findet. Für jedes gängige Betriebssystem sollten zumindest Software Initiatoren verfügbar sein. Ein Software iSCSI Target für Linux ist ebenfalls verfügbar. Kurze Erklärung: ein Target stellt den Speicher dem Initiator bereit. Als guten Einstieg für das Aufsetzen eines iSCSI Initiator und iSCSI Targets unter Linux kann ich "A Quick Guide to iSCSI on Linux" empfehlen --Daniel Paul 10:17, 2. Jun 2005 (CET)

Rechtschreibfehler

Hallo, ich habe von dem Thema so ziemlich keine Ahnung. Aber das Wort "dedizirrten" in dem Satz

"Das SAN wurde entwickelt, um dem Verwaltungsproblem von dedizirrten Festplatten in Server-Systemen bzw. Network Attached Storage-Systemen entgegen zu wirken, da bei jenen Systemen eine effiziente und flexible Nutzung der Speicherkapazität nur eingeschränkt möglich ist."

(steht direkt unter "Entwicklung und Funktionsprinzip") kommt mir ziemlich falsch vor.

Was soll das heißen? "Dezidierten" oder Dedizierten"? Könnte das mal jemand verbessern? --Morido 13:19, 27. Mär 2005 (CEST)

Das muss "dediziert" heißen und ist anscheinend bereits korrigiert. --Taxi1729 (Diskussion) 17:51, 23. Nov. 2014 (CET)

Zusatz zur Definition Virtualisierung

Beim -echten- Virtualisieren im SAN (bzw. im Storage Controller)erfolgt kein Partitionieren einer virtuell definierten "Festplatte". Es wird vielmehr ein Datenpool definiert, der, abhaengig von der Ebene in der die Virtualisierung verwaltet wird, meherere physikalische Festplatten oder auch mehrere Storage Systeme umfassen kann. Dieser Pool wird dann in Datenbereiche unterteilt. Jeder dieser Datenbereiche besitzt alle Eigenschaften einer physikalischen Festplatte, wie RAID Level und eine bestimmte Grosse, wobei diese fuer jeden Datenbereich (sprich: Virtelle Disk)unterschiedlich sein kann (hier liegt auch der grosse Unterschied zum im Artikel erwaehnten Partitionieren einer Festplatte: Alle Partitionen habe denselben RAID Level, naemlich den der darunterliegenden Festplatte). Dese sog. LUN wird dann einem oder mehreren Servern im Storage Netzwerk zugewiesen. Das Betriebssystem der Server "sieht" lediglich eine SCSI-Disk, die wie eine normale, direkt angeschlossene Festplatte verwendet werden kann. Storage Virtualisierung hat zwei grundsaetzliche Vorteile: 1. Eine virtuelle Disk kann jederzeit, und haeufig auch im Online-Betrieb vergroessert werden. 2. Eine virtuelle Disk kann, durch hinzufuegen von physikalischen Festplatten oder Storage Controllern "beschleunigt" werden, d.h. eine hoehere Performance liefern.

Dazu kommt, dass virtualisierte Daten einfacher migriert werden können, da die Anbindung für den Host bestehen bleibt und nur unter der Virtualisierungs-Engine die physikalischen Daten auf ein anderes Storage Subsystem kopiert werden müssen. Der Host selbst bekommt davon nichts mit. Auch für Copy-Services eignet sich eine Virtualisierungs-Engine als kostengünstige Alternative gegenüber den eingebauten, meist lizenzpflichtigen Features der Storage Subsysteme.

Das ist Speichervirtualisierung. Im Gegensatz dazu ist SAN-V. ein Aufbau ähnlich Ethernet VLANs, bei dem virtuelle SANs auf einer Fabric gefahren werden können und die Geräte flexibel auf die SAN-Fabrics verteilt werden können. Außerdem ist typischerweise eine lose Kopplung von virtualisierten SANs möglich. Ich habe den Abschnitt komplett rausgenommen, da ausschliesslich Funktionalitöt eines Raid-Controllers beschrieben wurde. --Taxi1729 (Diskussion) 00:25, 25. Dez. 2012 (CET)

Anwendungsgebiete?

Fuer einen Laien wie mich ist es sehr schwer nachvollziehbar, wofuer ein SAN gut ist. Kann jemand bitte einige Beispiele nennen, die deutlich machen: - Wer benutzt SANs? - Wozu sind SANs gut? (nicht vom technischen her betrachtet, sondern vom Nutzen fuer den Anwender, also als Beispiel: nicht "Narkose bringt den Patienten in einen schlafaehnlichen Bewusstseinszustand" sondern "Narkose ermoeglicht dem Patienten eine schmerzfreie OP"

Vielen Dank und ciao

SANs machen dann wirklich richtig Sinn, wenn ein Server sehr viel Speicherplatz verwalten muß.

Beispiel: Ein Server soll 20 TB Daten vorhalten können. Bei aktuellen 500 GB Festplatten (die 750 GB Laufwerke gibt es wohl noch nicht für Fibre-Channel) benötigt der Server dafür 40 Festplatten. Eine so große Anzahl bekommst du mit der üblichen Direktanbindung nicht an den Server angebunden. Auf dem Mainboard gibt es gar nicht genug Steckplätze, um genug Controller für alle Festplatten einzustecken und der hohe Anlaufstrom der Festplatten (es laufen ja 40 Elekromotoren quasi gleichzeitig an (ok, da gibt es auch noch ein paar kleine Tricks), würde dem Netzteil den Rest geben.

Da benötigt man dann ein SAN, um die elektrische Last auf mehrere Netzteile zu verteilen und die Anzahl der Controller zu minimieren. Üblicherweise werden in einem SAN jeweils 6-8 Festplatten in einem "Storage Array" zusammengepackt. Dabei handelt es sich um ein Gehäuse, mit eigenem Netzteil und einer "Backplane", so daß nur ein anschluß vom Storage Array zum Computer geführt werden muß. Benötigt man mehrere Storage Arrays, um alle Festplatten unterzubekommen, lassen sich die Datenleitungen zudem über einen Switch bündeln, so daß nur ein Controller im Server benötigt wird.

194.25.219.73 14:56, 16. Mär. 2007 (CET)

Gute Erklärung, Danke. So etwas schwiegermutterverständliches fehlt noch im Artikel, und zwar dringend! Maikel 00:28, 10. Nov. 2007 (CET)

Wenn ein Server sehr viel Speicherplatz benötigt kann er dies auch direkt vom Storage Subsystem beziehen (Direct-Attached-Storage) ohne SAN dazwischen. Genau so wenig bedarf es eines SANs um Netzteile zu entlasten. Ein SAN bietet vielmehr die Möglichkeit mehrere Server FC Ports (HBAs) auf denselben Storage FC Port zu schalten oder umgekehrt. Womit oft eine kostengünstigere und effektivere Ausnutzung des Storage Subsystems stattfinden kann. Gleiches gilt für Tape-Systeme.

Area vs. Array

Eigentlich nur eine Frage. heisst das jetzt Area oder Array ? In einer IHK Abschluss Prüfung findet sich der Begriff Storage Array Network und in Google eingegeben scheint es beides zu geben. --87.78.109.122 19:01, 1. Mai 2009 (CEST)

SAN steht für Storage Area Networks an welche man Storage Arrays (z.B. ein Diskschrank mit 256 Disks) anschliessen kann. Sind am SAN mehrere Servers angehäng kann man die Disks softwaregesteuert auf die Server verteilen. Unter einem Storage Array Network würde ich alle Storage Arrays (also meherere Diskschränke) verstehen, welche über ein SAN miteinander verbunden sind.Oceco 15:45, 10. Sep. 2009 (CEST)

LAN vs SAN

Schon mit folgendem Statement im Artikel habe ich extrem Mühe:

Damit ist es prinzipiell anders als ein Local Area Network (LAN)

Das seh ich genau umgekehrt. Prinzipiell anders sind Ethernet und Tokenring, aber auch nur wenn man die technischen Details anschaut (abhängig vom OSI Level den man betrachtet). Beide sind mal prinzipiell ein Netzwerk. Für den Laien ist ein Netzwerk vorersteinmal ein Netzwerk, ob da SCSI in FC-Frames oder ein NFS/SMB in TCP verpackt ist, kümmert den erst mal gar nicht. Mit den hier gemachten Äusserungen wird er die Unterschiede auch nie verstehen! Darum halte ich die Formulierung für sehr problematisch, zumal ein SAN auch über LAN/WAN implementiert werden kann. High Performance SANs, wie sie typischerweise in grossen Unternehmen installiert werden, unterscheiden sich in erster Linie auf dem Physical Layer (dedizierte HBAs, SW/LW). Ob ich über diese Hardwareinfrastruktur nun FC oder FICON laufen lasse, ist vorerst einmal unerheblich.

Ein SAN (ich lasse nun mal FICON aussen vor) basiert auf dem SCSI-Protokol (Block-IO). Dies ist ein low-level Protokol zwischen CPU und (direct-attached) Disk-Peripherie (bitte genauer im MediaWiki ausformulieren, allenfalls verlinken).

Anhand diesem Artikel habe ich verstanden warum Wikipedia nicht als Referenz dienen kann (speziell was in diesem Artikel hier steht ist einfach sehr viel Stuss, v.a. aus Sicht eines global tätigem Unternehmens. Ich möchte aber Hand bieten diese Situation zu verbessern.

Ich würde hier im SAN / NAS-Umfeld gerne ein wenig mitarbeiten und hab aber keine Lust auf Editwars. Darum fange ich hier mal klein an. Damit alles klar ist: Meine Kenntnisse stammen aus dem Umfeld als Mitarbeiter von EMC und McDATA. Meine Kunden sind IBM, HP, EMC, Dell, HDS et al. Aus dieser Perspektive liegen einige Artikel / Bilder im SAN / NAS / iSCSI / FCoE etc. Umfeld arg im Nebulösen.-- Oceco 16:57, 11. Sep. 2009 (CEST)

Huch, ich bin überrascht! Meine Veränderungen haben überlebt, mehr noch sie wurden mit Ergänzungen verbessert! Danke! Lediglich die Produkterwähnung von HP MC /ServiceGuard passt nicht ins Bild. Vorschlag: Am Ende des erklärenden Artikel eine Tabelle erstellen mit einer Produktübersicht für die verschiendenen Komponenten von allen Anbietern (sind ja nicht so viele). -- Oceco 10:06, 19. Okt. 2009 (CEST)

Überholt?

ich hab das Gefühl das grosse Teile des Artikels überholt sind. Beispiel "...Standleitung..." --Itu 03:37, 2. Dez. 2009 (CET)

Warum? Was ist an einer Standleitung falsch? Ansonsten kann der Artikel durchaus verbessert werden. Konstruktive Beiträge sind immer willkommen. -- Oceco 21:58, 17. Dez. 2009 (CET)

Diagramm ist falsch

Im vorliegenden Diagramm bezüglich der Disks/LUN und der Anschlüsse sind irreführend (falsch). Man muss unterscheiden zwischen:

• Hard Disk Drives (HDD). Sie haben nur einen Datenpfad-Anschluss (SCSI, SATA, etc.)
• Logical Unit Number (LUN), eine logische Disk
• RAID Konfiguration 0=Beschleunigung, 1=Spiegelung, 5=Beschleunigung und Parität

Das Diagramm suggeriert, dass ein HDD zwei physische Datenpfade hat, was nicht der Fall ist. Auch die Unterschriften zu den HDD sind falsch: Die mittlere Disk soll RAID 5 sein mit zwei LUNs ist Nonsens, denn RAID 5 braucht minimum 3 LUNS. Die rechte Disk mit RAID 10 muss eine gerade Anzahl LUNS haben, zudem macht eine Spiegelung von Daten auf die gleichen HDD keinen Sinn! Um die Sache noch kompizierter zu machen, muss man unterscheiden wo RAID implementiert wird:

1. Im Storage-Array (high-end Lösung)
2. Auf dem Server

Ich hab mal versucht das grafisch korrekter darzustellen. Upload demnächst! -- Oceco 21:58, 17. Dez. 2009 (CET)

SAN-Architektur (Entwurf)

Bitte beachten: Dies ist mein erster Entwurf und soll lediglich helfen, ein gemeinsames Verständnis zu einem SAN zu entwickeln. Zuvor war da ja all zu vieles schwammig formuliert.

Kurze Erläuterung sei erlaubt:

• Oben sind die Server (A und B)
• In der Mitte das SAN (blau ausgezeichnet)
• Unten das (die) Speichersystem(e) / Storage Array

Im Storage Array sind fünf Disk (D1-D5) gezeigt, jeweils in fünf gleiche Partitionen (P1-P5) unterteilt. Diese Partitionen sind durch den Storage Array zu verschiedentlichen RAID-Levels zusammengebunden und werden den Servern entsprechend zugeordnet (grün zu Server A, gelb zu Serber B). Diese Partitionsverbunde werden dem Server als eine LUN, also wie eine einzelne Disk präsentiert (dargestellt durch die gestrichelten Linien). Andererseits werden die pinkfarbigen Partitionen direkt dem Sever B zur Verfügung gestellt. Mit einer Host basierenden RAID-Lösung können die beiden LUNs z.B. zu einem RAID 1 (Spiegelung) verbunden werden. Wie man erkennen kann, sind sämtliche Komponenten im SAN und im Storage Array redundant vorhanden. Nur die Server nicht. Dies lässt sich durch eine Cluster-Lösung eliminieren, was aber im Katastrophenfall nicht hilft. Deshalb ist noch ein Remote SAN am rechten Rand angedeutet, wo eine Failover-Lösung für das ganze Rechenzentrum implementiert werden kann. Die Disk D3/P3 hab ich bewusst nicht zugeordnet, denn sie kann als Hot Spare genutzt werden (sofern der Storage Array es unterstützt)

Was ich soweit mal grob grafisch dargestellt habe, gilt es nun hier zu diskutieren und in den Artikel einzupflegen.

Freue mich auf eine rege Mitarbeit und konstruktieven Feedback! Ach ja, das Werk erhebt Anspruch auf Unvollständigkeit! -- Oceco 22:42, 17. Dez. 2009 (CET)

Habe gerade realisiert, dass im Diagramm noch eine Lösung für den Ausfall eines HBAs fehlt (Failover). Zudem bieten die Hersteller auch einen Lastausgleich über die beiden HBAs an. Ich poste dies nur, damit ich es nicht wieder vergesse. -- Oceco 22:54, 17. Dez. 2009 (CET)

Literatur

Ulf Troppens, Rainer Erkens: Speichernetze. dpunkt, Heidelberg 2002. ISBN 3-89864-135-X ... aktualisiert -> zweite Auflage, ISBN und da es mehr als zwei Autoren sind (siehe http://www.speichernetze.com/pageID_5651953.html), ein u.a. angefügt ;-) John Doe@--93.223.243.244 23:38, 25. Apr. 2012 (CEST)

Falsche Übertragungsgeschwindkeit

Im Text heißt es "Sie arbeiten heute mit Übertragungsraten von bis zu 16 Gbit/s. Da sie ein spezielles, an die Anforderung der Massenspeichernutzung angepasstes Protokoll verwenden, sind Übertragungsraten von theoretisch 1,6 GB/s möglich. "

Rechnet man jedoch die 16GBits in Gigabyte um landet man bei 2GB/s, damit wäre die heute übliche Übertragungsgeschwigkeit über der therotisch möglichen - das aber kann schlecht stimmen... (nicht signierter Beitrag von 62.225.156.156 (Diskussion) 14:00, 18. Okt. 2019 (CEST))

Schau mal im Anschnitt "Bandbreite", wo ich das im letzten Posting erklärt habe. Stickwort 8B10B --Taxi1729 (Diskussion) 14:08, 18. Okt. 2019 (CEST)