Ein neuer Trend verlagert die Speicherverwaltung von proprietären Array-Controllern auf reguläre x86-Server oder gleich in die Cloud. An den Beispielen GlusterFS & Openstack Swift stellt speicherguide.de zwei aktuelle Open-Source Software-Speicherkonzepte vor.

Max Lessel

Strenggenommen ist jedes Array eine auf Software basierende Speicherlösung. Irgendwo arbeiten Programme auf SAS- sowie FC-Controllern und machen aus einzelnen Platten RAIDs mit Fibre-Channel-Targets. Was ist also das besondere an dem »Software based Storage«-Trend?

Geschlossene Systeme werden als Ganzes vom Hersteller supportet und laufen in der Regel sehr schnell. Dafür ist der Anwender auf die Komponenten und die dazugehörigen Software-Lösungen des jeweiligen Anbieters gebunden und muss viel Geld investieren. Migrationen auf andere Systeme sind komplex und teuer.

Software-basierte Systeme laufen in der Regel etwas langsamer, offerieren dem Administrator jedoch alle Freiheiten bei der Wahl der Komponenten. Quelloffene Open-Source-Lösungen binden den Anwender dabei nicht einmal an einen speziellen Software-Lieferanten. Somit fallen Software-Speicher im Vergleich zu traditionellen Arrays auch viel günstiger aus. Im Gegenzug wird es natürlich schwer, Support für solche Lösungen zu erhalten.

Stand heute lassen sich nur Teilbereiche der IT-Infrastruktur sinnvoll mit softwarebasierten Speichersystemen abbilden. Bereiche mit hohen Anforderungen an Performance und Verfügbarkeit werden bei klassischen Fabric-Lösungen bleiben (z.B. Datenbanken, business-kritische Apps). Aber andere Gebiete wie Backup-, Archiv-Lösungen, Fileservices und Multimedia-Bibliotheken können jedoch sehr wohl mit günstigen softwarebasierten Lösungen arbeiten.

Cloud-Lösungen pushen Software-Speicher

Hinzu kommt die Fülle moderner Cloud-Lösungen wie beispielsweise Drop-Boxen, für die sich softwarebasierte Speichersysteme vortrefflich eigenen. Bei Cloud-Lösungen steht die Performance alleine schon aufgrund der WAN-Anbindung nicht im Vordergrund. Die Speicherkommunikation läuft über routbare IP-Protokolle und verzichtet weitgehend auf isolierte SAN-Technologien. Cloud-Storage-Lösungen arbeiten nach dem Scale-Out-Prinzip: Geht die freie Kapazität zur Neige, fügt der Betreiber einfach weitere Storage-Nodes hinzu – und wenn‘s geht nicht an einem vorgegebenen Standort, sondern irgendwo in der Welt.

Cloud-Storage rückt dabei auch Objekt-Storage-Ansätze stärker in den Vordergrund. Die gibt es zwar bereits seit Jahren, doch kommen Sie bislang eigentlich nur in Nischen zum Einsatz. Dateisysteme und Ordner gibt es bei Objektspeichern nicht. Via http-basierter »REST-API« liefern die Clients ihre Dateien nebst Metadaten am Objekt-Speicher an. Wo und wie dieser die Daten dann auf Platten sichert, interessiert den Client nicht.

Gluster Cluster

Cluster-Dateisysteme verteilen die Daten auf verschiedene Nodes. Das sind in der Regel reguläre PC-Server mit Hardware-RAID-Controllern und vielen SAS- oder SATA-Laufwerken. Konzepte wie Striping und Spiegelung sorgen dabei für ausreichend Performance, Skalierung und Ausfallsicherheit. Viele traditionelle Cluster-Speicher benötigen einen Verzeichnis-Node, welcher das Cluster-Directory sichert und weiß, welche Daten auf welchem Knoten liegen. Dieser Head-Node stellt den Flaschenhals im Speichercluster und auch einen Single Point of Failure dar. Das moderne »Gluster«-Dateisystem verzichtet auf diesen Head-Node. Der Trick liegt in der Architektur: Gluster verwendet einen simplen Hash-Algorithmus für die Verteilung der Daten auf den Knoten. Vereinfacht gesagt: Aus dem Dateinamen und der Zahl der Nodes errechnet Gluster, wo eine bestimmte Datei hingehört. Dieser Algorithmus ist dabei allen an dem Dateisystem angebundenen Clients bekannt. Damit verteilen sich die ein- und ausgehenden IOPS direkt auf alle Nodes im Gluster-Cluster, ohne dass es dabei Engstellen beim Zugriff über einen Proxy-Knoten gibt.

Fügt der Verwalter seinem Gluster-Verband neue Nodes hinzu, ändert sich der Algorithmus entsprechend. Zugriffe auf bestehende Dateien erfolgen dabei nach dem alten Schema, so lange, bis der Gluster-Verband über ein »rebalancing« die Dateistrukturen an die neue Verteilung angepasst hat. Dabei verteilt das GlusterFS die Daten nicht nur auf die Nodes. Es kann auch redundante Verbände erstellen, bei denen komplette Nodes ein oder gar mehrfach gespiegelt werden. Somit sorgt das verteilte Dateisystem nicht nur für Performance, sondern auch für die Ausfallsicherheit einzelner Nodes oder ganzer Rechenzentren.

Das GlusterFS gehört zu Red Hat. Wie bei allen Red Hat Produkten gibt es neben der kommerziell vertriebenen Variante (Red Hat Storage) auch ein so genanntes Upstream-Projekt, dass die Lösung kostenfrei zur Verfügung stellt.

Neben reinen Scale-Out-NAS-Diensten kann Gluster aber noch ganz andere Aufgaben erledigen. Red Hat führt aktuell die Gluster-Speicher-Technologie mit dem hauseigenen Virtualisierungsprodukt Red Hat »Enterprise Virtualization« zusammen. Dabei kommen Virtualisierungs-Nodes mit lokalen Platten und Gluster-Dateisystem zum Einsatz. So erhalten Anwender eine skalierende und ausfallsichere Virtualisierungsumgebung, ohne dafür teure SAN-Komponenten nutzen zu müssen.

In der Serie NAS im Eigenbau von speicherguide.de findet sich eine Anleitung, mit der interessierte Admins sich einen Gluster-Verband für Testzwecke mit virtuellen Maschinen aufbauen können.

REST im Objektstor

Objektspeicher arbeiten häufig als Archivlösungen, Cloud-Storage oder im Big-Data-Umfeld. Sie abstrahieren den logischen Storage vollständige von der dahinterliegenden Architektur. Kommerzielle Lösungen wie »CAStor« von Caringo setzen im Frontend einen Management-Node mit »REST-Api« ein. Die eigentlichen Daten landen dann auf vom Head-Node verwalteten Servern mit großen SATA-Platten. So etwas wie Raid kommt hier nicht zum Einsatz. Jedes abgelegte Objekt wird entsprechend der Policy-Vorgabe des Managers einfach auf mindestens zwei Speicher-Nodes auf verschiedenen Platten abgelegt. Die Verwaltungslogik sorgt auch dafür, dass die Redundanz beim Ausfall eines Nodes wieder hergestellt wird oder hinzukommende Nodes dynamisch eingebunden werden.

Swift:Quelloffener Objektspeicher

Neben den kommerziellen Ansätzen gibt es auch eine quelloffene Lösung: »Swift«. Der Objektspeicher ist Teil der aktuell populären Openstack-Familie, mit der sich private und öffentliche Clouds aufsetzen lassen. Openstack stammt ursprünglich von der Nasa und dem US-Provider Rackspace. Die Grundidee war es, eine der Amazon-Cloud ähnliche Lösung als Open-Source aufzubauen. Stand heute entwickeln viele Unternehmen Openstack weiter, darunter vor allem Red Hat, Intel und Rackspace.

Die Architektur von Swift ist auf Anhieb nicht leicht zu durchschauen aber schlüssig. Die einzelnen Storage-Nodes verwalten Container und Speicherpartitionen. So genannte Ringe steuern die Verteilung der Objekte auf die Partitionen und Container der Objekt-Speicher-Nodes und sorgen dafür, dass die vorgeschrieben Redundanz eingehalten wird. Swift ist »Mehr-Parteifähig« und daher auch an ein entsprechendes Nutzerverzeichnis (Keystone) angebunden. Zwei Indizierungsstufen (Container und Dateien innerhalb der Container) sorgen dafür, dass Anwender schnell an ihre Daten herankommen. In der Basis-Implementierung erhalten Anwender über das Web-Portal von Openstack (Horizon) Zugriff auf den Swift-Speicher.

Dank der dokumentierten REST-API können Unternehmen Swift jedoch problemlos in eigene Lösungen integrieren. Neben dem Betrieb mit eigenen Objektnodes lässt sich Swift aber auch als Objekt-Frontend vor einem GlusterFS betreiben.

Ein experimentelles Swift-Test-Setup ist leider ein wenig komplexer, als das im NAS-Artikel beschriebene Gluster-Szenario. Wer sich damit auseinander setzen möchte, findet hier eine gute Dokumentation.

Fazit

Software-basierte Storage-Systeme erfinden das Rad nicht neu und stellen bei unternehmenskritischen Kernanwendungen (noch) keine direkte Konkurrenz zu den 1st-Tier-Blocklevel-Speichern der klassischen Anbieter dar. Allerdings erledigen sie etliche Aufgaben günstiger und besser, als das teure Blockspeicher tun und werden somit die Einsatzgebiete der klassischen Arrays einengen. Speziell bei Cloud-Lösungen haben Software-Speicher die Nase vorn. Wer Cloud-Ansätze plant, wird an Software-basierten Speicher kaum vorbei kommen.