In kleineren Umgebungen wollen Verwalter zwar die Funktionen eines SAN nutzen, ohne dafür jedoch ein SAN mit allen dazu gehörigen Komponenten anschaffen zu müssen. In Teilbereichen funktioniert das sogar.

Max Lessel

Ein SAN setzt teure Speichersysteme und die aktiven Komponenten eines Speichernetzwerks voraus. Nimmt der Administrator ein paar funktionelle Abstriche in Kauf, bekommt er SAN-Features für kleine Umgebungen auch ohne FC oder iSCSI.

SAS-SAN

Über Serial-Attached-SCSI (SAS) binden Server in der Regel Bandbibliotheken und passive JBODs mit vielen Platten an. Einige Speicherhersteller offerieren jedoch auch Speichersysteme mit integriertem SAS-RAID-Controller und SAS als Host-Anbindung. Sobald diese Systeme über mehrere, parallel nutzbare SAS-Host-Anschlüsse verfügen, können sie Administratoren wie ein SAN-Speichersystem verwenden. Die nötigen SAS-HBAs für die anzubindenden Server kosten pro Port ab rund 100 Euro (Areca »ARC-1300-4x«, Dell »PERC H800«).

Vorteile der SAS-SAN-Anbindung: Hohe Bandbreite (6 Gbit/s) und damit arbeitet die SAS-Anbindung schneller als iSCSI. Es sind keine SAN-Switches erforderlich.

Nachteile von SAS: Die maximale Zahl der Hosts geben die HBA-Ports der Speicher-Controller vor. Zudem ist keine räumliche Teilung für ein ausfallsicheres Setup möglich, da die Kabellänge auf 10 Meter begrenzt ist. Theoretisch lässt sich ein SAS-SAN auch über Switches betreiben, diese sind jedoch noch nicht für Schlüsselkomponenten wie VMware zertifiziert.

NFS-SAN

Im Zusammenspiel mit Virtualisierungs-Lösungen von Vmware oder <b>Citrix</b> »Xen« kommt häufig auch NFS als SAN-Ersatz zum Einsatz. Die Zugriffe vom Hypervisor auf die Image-Dateien der virtuellen Disks kann problemlos über das File-Sharing-Protokoll erfolgen. Die Snapshot-Funktionen der zugrundeliegenden Dateisysteme ersetzen die Volume-Snapshot-Funktionen großer SAN-Maschinen. Dabei ist allerdings Vorsicht geboten.

Gerne nutzen Systemverwalter einen NFS-Server im lokalen Netzwerk und fahren damit über eine LAN-Verkabelung sowohl SAN als auch LAN-Daten. Wie bei iSCSI sollten Administratoren den NFS-Verkehr auf ein eigenes LAN-Segment abtrennen, so dass es zu keinen Bandbreitenengpässen kommt. Auch muss der NFS-Server über mehr als nur einen LAN-Adapter verfügen, um die parallelen Zugriffe mehrere Server abwickeln zu können. Zudem dienen mehrere Pfade der Ausfallsicherheit.

Apropos Ausfall: Ein einzelner PC-Server mit Platten und NFS-Diensten stellt einen »Single Point of Failure« (SPoF) dar. Der Ausfall einer einzelnen Komponente legt das komplette Pseudo-SAN lahm und bringt damit im Zweifelsfall dutzende virtueller Maschinen zum Absturz.

NFS-Server lassen sich auf Sekundärsysteme spiegeln. Das können sowohl Open-Source- als auch kommerzielle Lösungen sein. Das Ganze wird dann aber wieder relativ komplex und verschleudert obendrein 50 Prozent der Plattenkapazität für Redundanz. In vielen Fällen kommt dann ein iSCSI-SAN-System mit dualen Controllern schon wieder günstiger.

Vmware beispielsweise offeriert ab »vSphere 5« eine »vSphere Storarage Appliance«. Diese – nicht mit Hewlett-Packards »VSA« zu verwechselnde – Storage VM macht aus den lokalen Disks eines ESX-Hosts ein RAID mit NFS-Freigabe auf der Vsphere dann die eigentlichen VMDK-Dateien der virtuellen Maschine ablegt. Über ein dezidiertes LAN-Segment spiegeln die ESX-Hosts die NFS-Daten untereinander und schaffen so Ausfallsicherheit. Allerdings gehen dabei 75 Prozent der Brutto-Plattenkapazität für RAID 10 und 1:1 Spiegel der NFS-Freigaben verloren.

Fazit: Kostengünstige Alternative mit Risiken

Das SAS-SAN stellt tatsächlich eine kostengünstige Alternative zu FC und iSCSI in kleinen Umgebungen dar. NFS hingegen birgt viele Risiken und lässt sich nur mit herben Kapazitätsverlusten ausfallsicher einrichten.