Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Der Weg zum unternehmensweiten Speichernetz ist steinig


12.02.1999 - 

Der Weg zum unternehmensweiten Speichernetz ist steinig Network Attached Storage kann SAN sinnvoll ergänzen

MÜNCHEN (kk) - Das Konzept des Storage Area Network (SAN) läßt sich derzeit nur in Teilbereichen umsetzen, während Network Attached Storage (NAS) schon seit längerem verfügbar ist. Glaubt man den Herstellern, so lassen sich die Vorteile beider Ansätze künftig kombinieren.

Der Begriff Sto- rage Area Network (SAN) könnte zum DV-Wort des Jahres 1999 gewählt werden, betrachtet man die Vielzahl der Produktankündigungen, Absichtserklärungen und Kooperationsvereinbarungen der Hersteller zu diesem Thema. Das, wovon der IT-Manager träumt, ist in absehbarer Zeit aber nicht zu realisieren: ein schnelles Netz, über das Daten von unterschiedlichen Servern auf jede Art von Speicher transferiert beziehungsweise gespiegelt werden. Backups ließen sich mit Hil- fe der Speichersubsysteme un- abhängig vom Server durchführen.

Was dem SAN insbesondere noch fehlt, ist die passende Ma- nagement-Software. Analysten schätzen, daß es mindestens noch ein Jahr dauern wird, bis ein unternehmensweites SAN (Enterprise-SAN) mit heterogenen Servern und "Any-to-any"-Verbindungen aufgebaut werden kann. In Umgebungen mit homoge- nen und proprietären IT- Systemen hingegen sind SANs bereits seit langem etabliert. Ein Beispiel liefern die Escon-Verbindungen bei Mainframes, bei denen ebenfalls Speichersubsysteme und Bandbibliotheken vom Host abgekoppelt sind. Allerdings dient diese Trennung in erster Linie der Leistungssteigerung der Systeme.

Eine andere Schwachstelle im SAN-Konzept hat Rolf Lange, Geschäftsführer der deutschen Niederlassung von Auspex, ausgemacht. Seiner Meinung nach ist ein eigenes Speichersubnetz für den bloßen File-Transfer nicht geeignet: "Immer dann, wenn Daten zum Client transferiert werden, ist ein dediziertes Speichernetz Unsinn, da die Informationen dann über zwei Netze, das SAN und das LAN, zu übermitteln sind." Für so einen Fall sei das Konzept des Network Atta- ched Storage (NAS) vorzuziehen. "Ein SAN bietet sich dann an, wenn ein reiner Blockdatentransfer, also beispielsweise von der Oracle-Datenbank zum SAP-Server, stattfindet und nur das Ergebnis an den Benutzer weitergereicht wird."

Ein NAS baut demgegenüber auf einem herkömmlichen LAN auf, in dem ein File-Server den I/O-Verkehr regelt. Das Storage Area Network stellt dagegen ein eigenes Hochgeschwindigkeitsnetz - meist auf Basis des Fibre Channel (FC) - dar, das ausschließlich für den Datenverkehr inklusive Backup bestimmt ist.

SAN und NAS unterscheiden sich hauptsächlich bezüglich der verwendeten Protokolle und der Verbindungen.

Während ein SAN ein verkapseltes (encapsulated) SCSI-Protokoll fährt, nutzen Network-Attached-Storage-Konzepte die File-Server- Protokolle NFS für Unix, CIFS für Windows oder HTTP für das Internet. SANs basieren meist auf Fibre-Channel-Verbindungen, NAS dagegen auf TCP/ IP-Netzen (Ethernet, FDDI, ATM).

Daraus ergeben sich auch die jeweiligen Vorteile der beiden Architekturen. Im SAN werden Blockdaten schnell transferiert, Speicher- und Bandsysteme lassen sich remote mit einem Server verbinden. NAS-Konzepte erlauben dem Anwender schon heute den gleichzeitigen Datenzugriff über Plattformgrenzen hinweg.

Speicherspezialist EMC unterstützt das SAN-Konzept und hat nun eine Arbeitsgruppe ins Leben gerufen, die allgemeingültige Spezifikationen zum Verwalten von Fibre-Channel-Geräten erstellen will. Teilnehmer sind eine Vielzahl von Lieferanten, die Hubs, Switches, Speicherperipherie oder Software produzieren. Als Basis dient der Initiative das Simple Network Management Protocol (SNMP). Geplant ist, im Mikrocode jedes FC-Geräts einen Agenten, die Management Information Base (MIB), zu plazieren, der die Verwaltung möglich machen soll.

Die Spezifikationen sollen noch in diesem Quartal der Internet Engineering Task Force (IETF) zur Standardisierung vorgelegt werden. Möglicherweise kommt es dabei zu einem Streit mit der Storage Network Industry Associa- tion (Snia), die sich ebenfalls mit einem einheitlichen Management für FC-Geräte beschäftigt. Hersteller wie Brocade, Sun und IBM nehmen unter anderem aus diesem Grund nicht an der EMC-Initiative teil.

Sun Microsystems entwickelt zudem derzeit einen Satz von Java-APIs als Teil der hauseigenen "Store-X"-Kampagne. Damit soll eine allgemei- ne und offene Struktur für das Speicher-Management geschaffen werden. Analysten betrachten die Bemühungen von Sun zudem als Versuch, mit allgemein verfüg- barer Basistechnik der Marktmacht von EMC zu Leibe zu rücken.

Das Vorpreschen von EMC beim FC-Management hat einen einfachen Hintergrund: Marktanalysen zeigen, daß sich durch Internet und E- Commerce die gespeicherten Datenvolumina jedes Jahr verdoppeln. Die fehlenden Verwaltungswerkzeuge verhindern aber seit mindestens zwei Jahren, wie EMC glaubt, den breiten Einsatz von SANs - und damit geht den Speicherherstellern und unabhängigen Softwarehäusern sehr viel Geld verloren.

"Die Anwender fragen beim SAN-Konzept zuerst danach, wie sie die Lösung verwalten können", bestätigt auch Jeff Barckley von IBMs Storage Systems Divi- sion. Das sei ein anderes Verhalten als früher, wo beispielsweise immer mehr und immer leistungsstärkere Prozessoren angeschafft wurden und erst nach großen Investitionen gefragt wurde, wie diese Rechenpower zu managen sei. Die Verwaltungskosten bei Speichern schlagen kräftig zu Buche. IBM schätzt beispielsweise, daß die Verwaltung von 1 MB im Jahr 3,50 Dollar kostet, während die reine Speicherung nur 33 bis 35 Cent im Jahr ausmacht.

Noch nicht gelöst ist im SAN auch die Frage, wie in einem heterogenen Umfeld die einzelnen Dateiformate übersetzt werden sollen. Denkbar wäre die Übersetzung von einem Format zu einem anderen "on the fly", also während der Übermittlung. Eine andere Option, die auch von der Snia verfolgt wird, ist die Entwicklung eines generellen File-Systems speziell für SANs. Man könnte sich auch auf ein schon bestehendes Format als De-facto-Standard einigen. Als aussichtsreicher Lieferant dafür gilt die in Mountain View ansässige Veritas Software. Die Kalifornier haben sich jedoch auf das Management von Speichern im SAN spezialisiert und binden die als "Fabric" bezeichneten Verbindungsteile wie Switches oder Bridges (noch) nicht in ihr Konzept mit ein.

Der US-Hersteller Network Appliance versucht, ebenso wie Mitbewerber Auspex im Markt für NAS-Server, zusammen mit Brocade, Hersteller von Switches auf Basis des FC, den Spagat zwischen NAS und SAN. "Der Nachteil von unterschiedlichen Applikations-Servern im LAN ist, daß jeder seine eigenen Speicheranforderungen hat", erklärte Andreas König von Network Appliance in München. Werden jedoch SAN und NAS über einen FC-Switch kombiniert (siehe Grafik Seite 35) und die Daten von der Applikation getrennt, sollten die Vorteile wie eine zentrale Datenverwaltung, bessere Skalierbarkeit und höhere Fehlertoleranz möglich sein.

NAS und SAN

Ein SAN ist ein eigenes Speichernetz, meist auf Basis des Fibre Channel (FC), und verwendet als Protokoll Encapsulated SCSI. Das File-System liegt auf dem Applikations-Server. SANs eignen sich für geclusterte Applikationen und zentral verwaltete Datenpools.

Im NAS-Konzept wird ein File-Server für den I/O-Verkehr in ein LAN eingeklinkt. Das File-System liegt auf dem Speicher-Server. NAS nutzen TCP/IP-Netze wie Ethernet, FDDI und ATM und die Protokolle NFS, CIFS und HTTP. NAS eignen sich insbesondere für den Zugang von Servern und Desktop-Clients zu File-Daten. Gemischte Windows- Unix-Umgebungen sind möglich.