TU Wien | ZID | ZIDline 10 | SAN Storage System
Helmut Mastal, Werner Steinmann
Storage-Systeme erweisen sich langfristig ökonomischer als Einzel-Plattenspeicher gleicher Größe. Während größere Storage-Systeme von einigen hundert Terabyte Größe schon seit längerer Zeit verbreitet sind, treten jetzt auch mittlere Storage-Systeme ab der Größenordnung von 10 Terabyte zunehmend in Erscheinung. Voraussetzung ist, dass auf den Speicher von einer größeren Zahl von Applikationen oder Servern zugegriffen werden kann. Das kann durch ein auf Fibre Channel Technologie basierendes SAN (Storage Area Network) erreicht werden. Das SAN kann auch durch einen NAS-Head ergänzt werden, mit dem Shares des Storage-Systems an eine Vielzahl von Desktop-Clients, für die der Anschluss an das SAN unökonomisch wäre, herangeführt werden können.
Die Abteilung Standardsoftware des ZID hat im Jahr 2003 ein SAN aufgebaut, an das einerseits ein Hitachi Storage System von derzeit 7 Terabyte Größe sowie ein älteres RAID-System von 2 Terabyte, andererseits die Hosts des Software Distribution Servers und des Goodie Domain Servers und ein NAS-Head angeschlossen sind.
Zu Beginn der Neunzigerjahre war technologisch eine große Performance-Steigerung sowohl von Computer- Prozessoren und Memory als auch bei den peripheren Geräten wie Disk-Drives abzusehen. Die bisher bei Direct Attached Storage (DAS) verwendete Methode mit den Protokollen SCSI und IDE hätte trotz Weiterentwicklung ein gravierender Engpass im gesamten Datendurchsatz von Systemen werden können. Auch war die Entfernung der Endgeräte bei diesen Methoden auf wenige Meter eingeschränkt. War das Ansprechen eines DAS Geräts von mehreren gleichartigen Systemen schon sehr schwierig zu implementieren, so ist der gleichzeitige Zugriff mit Unix und Windows praktisch unmöglich.
Fibre Channel konnte bei den drei genannten Problemen einen ganz wesentlichen Fortschritt bringen. Fibre Channel besteht im Wesentlichen aus drei Protokollschichten: der physische Layer ist i.a. Glasfaser, kann aber auch Kupfer sein, das eigentliche Fibre Channel Protokoll, das Anwendungsprotokoll, welches sehr oft an Fibre Channel angepasstes SCSI ist, aber viele andere Protokolle sind über Fibre Channel definiert. Mit Fibre Channel können je nach verwendetem Laser Übertragungsgeschwindigkeiten von 1 Gigabit oder 2 Gigabit erzielt werden, noch höhere Übertragungsleistungen sind in Entwicklung.
Bei den Entfernungen der Endgeräte konnten ganz wesentliche Distanzvergrößerungen erreicht werden: für Kupfer bis zu 24 Meter, für Multi-Mode-Glasfaser bis zu 500 Meter, für Single-Mode-Glasfaser mit Long Wave Laser bis zu 10 km, mit Extended Long Wave Laser bis zu 80 km. Die maximale Entfernung hängt von den in den so genannten GBICs (Gigabit Interface Converter für 1 Gigabit) oder SFPs (Small Form Factor Plug für 2 Gigabit) eingebauten Lasern ab. Noch größere Entfernungen von vielen hunderten Kilometern wurden mit Protokollumsetzern und optischen Extendern schon getestet. Die Endgeräte sind bei der Verwendung von Fibre Channel i.a. keine Single Disks mehr, sondern Storage-Systeme mit bis zu 1000 Disk-Drives, die über entsprechend leistungsfähige und intelligente Controller verfügen (meist RAID-Controller). Es wird damit wesentlich einfacher, mehreren Systemen (auch von unterschiedlichen Herstellern) den Zugriff zu einem Storage-System zu ermöglichen, aber auch unerwünschte Zugriffe zu verbieten. Noch nicht gelöst ist damit der simultane Zugriff auf das gleiche Filesystem von mehreren Rechnern. Hier müsste sich erst eines der Sharable Filesysteme als Standard durchsetzen, das herkömmliche Unix Filesystem ist dafür nicht geeignet.
Schon zu Beginn der Fibre Channel Entwicklung war an ein Fabric (Gewebe) gedacht, also an die totale Vernetzung von potentiell vielen Hosts mit potentiell vielen Storage-Systemen über Fibre Channel Switches. Es setzte sich zwar zunächst die auf Hubs basierende Arbitrated- Loop-Topologie wegen der einfachen Herstellung und Handhabung durch, hatte aber den großen Nachteil der unbeschränkten Fehlerausbreitung und der beschränkten Gesamt-Performance. Fibre Channel Switches werden mit 8 bis zu 128 Ports angeboten, sie stellen das Herzstück eines Fabric dar und gestatten im Normalfall das gleichzeitige Durchrouten von Messages auf allen disjunkten Portpaaren mit voller Performance. Der Konfigurationsaufwand ist bei Switches zwar größer als bei Hubs, aber wegen der weitgehenden Selbsterkennung der Fabric-Topologie vertretbar. Meist ist bei Switches auch Zoning möglich, das ist das gegenseitige Abschotten von Verbindungsgruppen eines Switches, um verbotene Zugriffe zu verhindern. Ähnliches kann aber bei Hitachi Storage-Systemen mit der Feature Host Storage Domain erreicht werden. Weit entfernte Switches werden über Trunkleitungen zusammengeschlossen.
Um eine hohe Verfügbarkeit zu erreichen, versucht man meist Switches redundant in einem Fabric anzulegen, sodass immer mindestens zwei Pfade von einem Host zu einem Storage-System führen. Der Anschluss der Hosts an das Fabric erfolgt über HBAs (Host Bus Adapter), das sind Interface-Karten, die auf einem Systembus sitzen und Fibre Channel Anschlüsse ähnlich den GBICs (bzw. SFPs) haben. HBAs werden mit speziellen Fibre Channel-Drivern vom Betriebssystem bedient.
Die Gesamtheit aus Fabric, Switches, Storage-Systemen und Hosts nennt man wegen einer gewissen topologischen Ähnlichkeit mit einem LAN auch SAN (Storage Area Network). Es gibt aber wesentliche Unterschiede zwischen LAN und SAN, so kennt ein SAN keine Kollisionen. Grundsätzlich ist das IP-Protokoll auch in SANs möglich, aus Sicherheitsgründen wird dies aber meist vermieden. Andererseits werden die Inhalte von Storage-Systemen oft auch über das IP-Protokoll mit NFS oder CIFS (Samba) verbreitet. Man spricht dann von einem NAS (Network Attached Storage). Ein Server, der die Verbindung zwischen SAN und NAS herstellt, heißt NAS-Head.
Die physischen Disks eines Storage-Systems werden zu Gruppen von 3 bis 8 Drives, so genannten RAID- Gruppen, zusammengefasst, die meist mit Hilfe des RAID-5 Prinzips einen Single-Disk-Fehler überstehen können. Da RAID-Gruppen meist für die praktische Verwendung als Filesysteme zu groß sind, werden sie in so genannte LUNs (Logical Units) unterteilt. Es entsteht damit eine weitere Adressierungsdimension neben Controller, Target und Partition von Platten. Bei einem NAS werden hingegen immer logische Filesysteme an die Clients angeboten.
"Speichergewebe" (Fabric)
Bei der Software-Distribution an der TU Wien besteht und bestand immer ein relativ hoher Bedarf an Massenspeicher, wenn man als Vergleich die Anforderungen für typische Workstations oder Abteilungsserver heranzieht. Man könnte den Umfang auch so ausdrücken, dass unser System irgendwo zum Midrange zählt, also eher außerhalb üblicher PC-Server-Anwendungen liegt, aber auch nicht zum Highend gerechnet wird. Damit sind gleichzeitig einige Parameter bei den Storage Systemen festgelegt, wie die Speicherkapazität, die Verkabelung oder die Über- tragungsraten, die alle ebenfalls einen mittleren Bereich abdecken sollen. Zusätzliche Bedingungen in unserem Arbeitsbereich ergeben sich aus dem Ziel, möglichst ausfallssicher und zuverlässig die gespeicherte Software im ganzen Universitätsbereich anzubieten und zu verteilen.
Bei der Anbindung von Storage an Server kann man drei gängige Szenarien unterscheiden:
Natürlich sind verschiedene Kombinationen dieser Grundvarianten möglich und werden je nach Bedarf auch eingesetzt.
DAS ist eine Bezeichnung für die wahrscheinlich verbreitetste Art, Storage einfach direkt an einen Server anzuschließen. Das kann intern (im Systemgehäuse) oder in einem externen Gehäuse realisiert sein. Für die externe Verbindung gibt es eine Anzahl von bewährten Interfaces wie SCSI oder Fibre Channel (FC) und neuen Möglichkeiten wie iSCSI (SCSI über IP-Netzwerke) oder Infini Band.
NAS bezeichnet ein Storage Device, das direkt an ein IP-Netzwerk angeschlossen wird. Diese Konfiguration erlaubt jeder Maschine im Netzwerk prinzipiell Zugriff auf das NAS. Ein wichtiges Kennzeichen von NAS ist der Zugriff auf File-Ebene, der über File-Sharing Protokolle wie NFS oder CIFS geschieht; NAS-Geräte sind mehr oder weniger dedizierte File-Server.
SAN steht für ein spezialisiertes Netzwerk, das mit hoher Geschwindigkeit heterogene Storage-Systeme und Server verbindet. Die Storage-Systeme sind z.B. ganze Schränke mit Platten in Form von RAIDs (Redundant Array of Independent Disks). Das SAN bietet den Zugriff auf die Daten auf Block-Ebene, ähnlich wie DAS, aber im Gegensatz zu NAS.
Die Entwicklung führte vom Anschluss von immer mehr einzelnen SCSI-Platten und DAT-Laufwerken zur Anschaffung eines RAID DEC StorageWorks 410 im Jahre 1996. Bald folgte ein weiteres RAID DEC Storage Works 450 und wurde in eine redundante Konfiguration des Software Distribution Servers swd.tuwien.ac.at integriert. Die DAT-Laufwerke waren in der Zwischenzeit durch DLT-Laufwerke ersetzt worden, die einzeln an die Server angeschlossen wurden.
Eine wesentliche Erneuerung im Jahr 2000 war der Übergang zu einer neuen Generation von Speichersystemen. Das hybride MetaStor RAID-System 3702 von LSI erlaubt einerseits, Platten an fünf interne SCSI-Busse anzuschließen, das Host-Interface hingegen ist ein Fibre Channel Anschluss pro Controller. LSI beliefert(e) als OEM Hersteller auch Sun und dort gab es ein baugleiches Modell unter dem Namen A3500FC. Dieser Umstand war natürlich ein Vorteil für uns, denn dadurch war der Support in einer Umgebung mit Sun-Geräten auch von dieser Seite klar.
Bereits seit 1999 wurden zwei Overland DLT7000- Wechsler mit je 15 Slots an einer dedizierten Maschine über ein eigenes 100 MBit Netzwerk für Backups eingesetzt. Diese 2 Geräte wurden am Ende ihrer Lebensdauer durch Upgrade-Austausch durch zwei baugleiche DLT8000-Wechsler ersetzt und um ein weiteres ergänzt. Wie bei den RAIDs wurde auch hier der SCSI HVD Anschluss abgelöst, in diesem Fall nicht durch FC, sondern durch SCSI LVD (low voltage differential). Und das interne 100 Mbit Ethernet für Backups wird schrittweise auf ein Gigabit Ethernet umgestellt.
Auch in die Richtung auf Ausfallssicherheit wurden immer wieder Verbesserungen mit den neueren Geräten eingeführt. Die alten Plattengehäuse hatten ein Netzteil und wenige Lüfter, die neuen haben mehrere Netzteile und so viele Lüfter, dass ohne weiteres der Ausfall eines dieser Teile verkraftet werden kann. Die Überwachung von Temperatur usw. wird durch EMUs (environmental monitoring units) mit entsprechenden Fühlern unterstützt. Die Anspeisungen erfolgen pro Gerät über verschiedene Stromkreise, jeweils zumindest ein Anschluss über USV und einer direkt am Netz. Die Systemplatten befinden sich in einem eigenen Gehäuse und sind als Software Mirror mit Solstice DiskSuite konfiguriert. Für die Datenplatten verwenden wir Hardware RAID und Solstice DiskSuite als eine Art Volume-Manager. Die Pfade zwischen Server und Storage Systemen sind ebenfalls durchgängig zweifach: zwei Controller im Host, zwei FC-Switches, zwei RAID-Controller bei den Platten, Glasfaser zwischen Host und Storage, zwei Loops (FC-AL) mit Kupferkabeln in den Disk Shelves im 19" Rack bzw. mehrere SCSI Busse bei älteren RAIDs. Fail- over und Load Balancing zwischen den Pfaden werden von aktuellen Betriebssystemversionen beherrscht, z. B. mit Traffic Manager unter Solaris. Die Storage Hersteller bieten aber für ihre Produkte oft auch eine ganze Palette von besser angepasster Zusatzsoftware. Wir verwenden z. B. für das LSI RAID einen RAID-Manager mit dem Modul RDAC (Redundant Disk Array Controller) und für unser Hitachi RAID den Hitachi Dynamic Link Manager (HDLM).
Im Umfeld von swd.tuwien.ac.at ging die Entwicklung immer mehr in Richtung auf (Fibre Channel) SAN - Storage Area Network: In unserem Fall ein Netzwerk aus (Rechner-)Systemen und Storage, das auf Fibre Channel Protokollen basiert, wobei auch die Disks selbst mit FC ausgestattet sind und nicht mehr mit parallelen SCSI Anschlüssen - SPI (SCSI Parallel Interface) heißt das jetzt im Unterschied zu den seriellen Varianten.
Es gibt in letzter Zeit auch eine sehr preisgünstige und interessante Entwicklung bei Serial ATA (SATA) Storage Devices, die vom PC-Bereich ausgeht und gerne intern in RAIDs (statt FC oder SCSI) eingesetzt wird. Und natürlich gibt es für Anforderungen, die jenseits von Fibre Channel liegen auch Interfaces wie ESCON (Enterprise Systems Connection) oder FICON (Fibre Connection).
1 GBit Fibre Channel hatte ja mit dem MetaStor 3702 von LSI in unsere Konfiguration Einzug gehalten, wobei das am Anfang eher Ersatz für die bis dahin übliche parallele SCSI-Verkabelung war und SAN zu der Zeit mehr Reklame als Realität war. Speziell Fibre Channel Arbitrated Loops (FC-AL) waren eine Methode, mit der das Limit von 8 oder 16 SCSI-IDs pro SCSI-Bus überwunden wurde. Und auch bei der Kabellänge bietet Fibre Channel viel mehr Spielraum als die parallele SCSI-Verkabelung. Ein Vorläufer von FC war z. B. schon seit 1992 SSA (Serial Storage Architecture), das aber nur von IBM forciert wurde.
Man darf sich von den vielen Bezeichnungen, die im Zusammenhang mit SANs auftauchen, nicht in die Irre führen lassen. Auch wenn die meisten Wörter Assoziationen zu Bekanntem hervorrufen, bedeutet z. B. Fibre Channel nicht Glasfaser, denn es gibt auch Kupferkabel, die die Spezifikationen erfüllen und typischerweise für kurze Strecken in (Platten-)Gehäusen verwendet werden.
Dagegen ist ein HBA - Host Bus Adapter - wie erwartet die Interface Karte zwischen Server/Workstation und dem Fibre Channel Netzwerk. Wir haben hauptsächlich FC-Adapter von JNI im Einsatz, die gut konfigurierbar sind und problemlos ihren Einsatzbereich abdecken. Unser Sun StorEdge T3 RAID ist aber z. B. an einem Adapter von Sun, einem OEM-Produkt von QLogic angeschlossen. Diese Kombination war im Bundle mit unserem SunFire 3800 Server inkludiert und erweiterte auch unsere Erfahrungen um eine weitere RAID-Konfiguration, unsere erste mit FC Disks und FC Host-Anschluss.
So richtig in Fahrt kam die Etablierung von SANs, als entsprechende Switches verfügbar (und bezahlbar) wurden. Der neue Begriff lautete dann Fabric (auch Switched Fabric) Topologie: ein Fibre Channel Netzwerk, das aus zwei oder mehr Switches zusätzlich zu den Hosts und anderen Geräten besteht.
In unserem Fall erfolgte die Einführung von zwei Brocade Silkworm 3200 Switches mit je acht Ports Anfang des Jahres 2003. Damit wurden die zwei Hubs (Vixel RAPPORT 1000 mit 8 Ports und Gadzoox Gibraltar GS mit 12 Ports) abgelöst, was eine deutliche Verbesserung beim Up und Down von Hosts mit Cluster-Zugriff auf das Storage-System bewirkte. Wobei auch schon der seinerzeitige Übergang von unseren älteren RAIDs mit HVD-Anschlüssen (high voltage differential) auf Fibre Channel Verkabelung mit Hubs (seit dem MetaStor 3702) ein deutlicher Fortschritt war. Ebenfalls mit den Switches begann der Umstieg auf eine neue Generation von Fibre Channel Komponenten mit 2 GBit, die kompatibel mit den Vorgängern mit 1 GBit sind. Aber leider werden z. B. die älteren JNI HBAs nicht mehr von neueren Solaris-Versionen unterstützt und können nur unter Solaris 8 weiter verwendet werden.
SAN der Abt. Standardsoftware, Konfiguration
Im Jahre 2002 wurde in der Abteilung Standardsoftware eine Evaluierung der Situation des signifikanten Massenspeichereinsatzes und -bedarfes inklusive Backup und Reserven im Hinblick auf eine homogene zentrale Storage-Lösung durchgeführt. Das Ergebnis der Untersuchung war die Entscheidung, eine Konfiguration zu finden, mit der nicht nur der Software Distribution Server sondern auch weitere Rechner der Abteilung eingebunden werden können, z. B. der Goodie Domain Server.
Im Juli 2003 wurde von uns ein Detailkonzept für ein neues Storage System ausgearbeitet. Es wurden verschiedene aktuelle Storage Systeme verglichen und vor allem auch die Integration in unsere vorhandene Umgebung genau untersucht. Gegen Ende des Jahres konnte dann ein Hitachi Thunder 9570V beschafft und ohne größere Umstellungen in Betrieb genommen werden. Die 95xxV Serie ist eine verkleinerte Ausgabe der Lightning 99xxV Enterprise Serie von Hitachi. Leider hatte gerade zur gleichen Zeit unser bisheriges Workhorse - das LSI Meta Stor 3702 - einen Ausfall und die Übertragung der Daten erfolgte nur teilweise von RAID zu RAID, der Rest musste von den Bändern nachgeladen werden. Damit konnte sich das Restore bewähren und nicht nur das Backup, was bis auf die Geschwindigkeit sehr zufrieden stellend verlief - beim Restore kann es ja nie schnell genug gehen. Das Sichern der Daten ist bei uns mit Full und Incremental Backups über einen ganzen Monat verteilt.
Hitachi Storage System, SWD Server SunFire 3800
Das Backup ist zurzeit über Gigabit Ethernet mit einem Gigabit Switch von Allied Telesyn AT 9410 GB in unser System integriert, aber (noch) nicht Teil des SAN. Die Gigabit Ethernet Entwicklung verlief übrigens zum Teil parallel zu der von Fibre Channel. Kurzfristig wird sich an unserem Backup System nichts Wesentliches ändern und welche Art von Anbindung dieser Geräte bei einer Erneuerung zum Zuge kommt, wird sich erst weisen. Zurzeit wären Bänder wie LTO-2 (Linear Tape-Open) eine interessante Alternative für ein SAN-konformes Backup.
Aus der Konfigurationsskizze zur Topologie unseres SAN ist vielleicht noch der NAS Head hervorzuheben. Aus Kosten-, Security- und Performance-Gründen werden an das SAN nur die Maschinen direkt angeschlossen, für die das sinnvoll erscheint. Die Arbeitsplätze der Mitarbeiter der Abteilung greifen indirekt über die Domain B unserer SunFire 3800, die als interner NAS Server fungiert, via 100 MBit Ethernet auf ihre Daten zu. Partition bzw. Domain bei der SunFire Serie beziehen sich auf spezielle Hard- und Software Einstellungen/Aufteilungen der Maschine und nicht auf eine der vielen anderen Verwendungen dieser Begriffe.
Das Management aller Komponenten unseres SANs erfolgt durch die für uns einfachsten Methoden, die aber leider für jedes der Geräte spezifisch sind. Zum Beispiel verwenden wir für das Hitachi Thunder 9570V einen eigenen PC mit einer Web-Applikation (Resource Manager) als Konsole für die Konfiguration und das allge- meine Monitoring des Systems. Für das Überwachungs-Interface ist eine andere Applikation (Hi-Track) auf dem PC installiert. Es gibt aber auch ein Command Line Interface für verschiedenste Plattformen zur Automatisierung von Vorgängen. Am RAID-Controller selber ist zusätzlich noch ein eigenes serielles und ein eigenes Ethernet-Interface für all die Arbeiten eingebaut, die über das normale User Interface nicht zu erreichen sind. Fast jeder Hersteller würde auch eigene Tools zur Verwaltung (s)eines SANs anbieten, z. B. Hi-Command von Hitachi oder Sun StorEdge Component Manager, aber das ist Overkill bei einem kleinen Netz.
Was ist bei unserer Konfiguration in nächster Zeit offen?
Wie schon erwähnt, wird bei Neuanschaffungen zu überlegen sein, wie weit das Backup in das SAN integriert werden kann. Ob das dann FC Geräte sein werden, oder wie die Proponenten von SCSI über IP meinen, dass der GigaBit Ethernet Entwicklung allein die nächste Zukunft gehört, wird man sehen.
Für die Weiterentwicklung der SCSI Disk Systeme, gleichgültig ob mit parallelen oder FC Interfaces, sind speziell Lösungen mit kostengünstigen SATA Disks o.ä. eine ernste Konkurrenz.
Und im Gegensatz zur derzeitigen Konfiguration, dass immer nur ein Host im SAN auf das gleiche Filesystem schreibend zugreifen kann, werden von uns echte Data-Sharing Filesystems wie Sistina oder CXFS für die Zukunft in Erwägung gezogen.
Für einige der in unserem SAN verwendeten Komponenten folgt eine kommentierte Liste von Referenzen. Leider sind die frei verfügbaren Unterlagen einzelner Anbieter oft nicht ausreichend, um eine Kaufentscheidung zu treffen oder ein System sinnvoll zu konfigurieren. Aber der Vergleich verschiedener Unterlagen zeigt schon die Kernpunkte auf, die man dann im direkten Kontakt mit dem jeweiligen Hersteller abklären kann, oder auf entsprechende Kursen, Seminaren usw.
Unsere FC Switches sind von Brocade: www.brocade.com, dem Marktführer bei FC Switches. Ein anderer wichtiger Hersteller von SAN Komponenten ist McData: www.mcdata.com
Der GigaBit Switch für unser Backup-Netzwerk ist von Allied Telesyn: www.alliedtelesyn.com
Unser erster FC Hub war von Vixel: www.vixel.com, ging im Oktober 2003 an Emulex, siehe z.B. www.emulex.com/corp/investor/vixel/ESGtechbrief.pdf. Emulex ist u.a. auch ein bekannter Hersteller von FC HBAs.
Der Hersteller unseres zweiten FC Hubs: www.gadzoox.com ging bankrott, die Konkursmasse kam im März 2004 an www.broadcom.com
Unsere aktuell verwendeten RAIDs kommen von www.hds.com - Hitachi Thunder 9570V und www.lsilogic.com - MetaStor 3702. Die Hitachi Lightning 99xxV Serie wird u.a. auch von HP und Sun angeboten. LSI hat bereits für viele andere Hersteller RAIDs produziert, z. B. Sun, SGI, IBM.
Unser StorEdge T3 RAID ist eine Entwicklung von Maxstrat und wurde im Jänner 1999 von Sun (www.sun.com) gekauft. Der Sun HBA an den unser T3 angeschlossen ist, stammt eigentlich von QLogic (www.qlogic.com), einem der führenden Hersteller in diesem Bereich.
Die Firma Sun hat im Storage Bereich viele Kooperationen mit verschiedenen Herstellern, aktuell sind z. B. ihre lower-end Storage Systeme von DotHill (www.dothill.com) und die high-end Systeme von Hitachi. Der mittlere Bereich wird von einer Weiterentwicklung des T3 abgedeckt.
Unsere RAIDs von LSI und HDS verwenden das real- time OS VxWorks von Wind River (www.windriver.com).
Unsere ersten zwei RAIDs bei der Software Distribution waren von DEC; die Nachfolge von DEC StorageWorks kam via Compaq an HP (www.hp.com/storage/).
Im midrange Storage Bereich ist EMC ein Konkurrent von Hitachi. EMC (www.emc.com) kaufte Anfang 1999 Data General und damit die CLARiiON Gruppe - darauf bauen ihre FC RAIDs auf.
Der Hersteller, von dem die meisten unserer HBAs stammen, JNI, ging im August 2003 an AMCC (www.amcc.com).
Zu FC, InfiniBand oder SATA gibt es Working Groups, Trade Associations usw. (www.fibrechannel.org, www.snia.org - Storage Networking Industry Association, www.infinibandta.org, www.serialata.org) Von solchen Web-Pages findet man weiter zu den White Papers und Unterlagen der beteiligten Firmen.
Zu den (OEM-)Partnern von Overland, dem Hersteller unserer Bandstationen, (www.overlanddata.com) zählen viele namhaften Firmen. Und natürlich werden von Overland auch Produkte für SAN-Umgebungen angeboten.
Zu den Entwicklungen bei den Filesystemen von Sistina oder SGI gibt es unter www.sistina.com und www.sgi.com/products/storage/software.html einige Informationen.