LizardFS: Software-defined Storage, wie es sein soll
Ein klassisches Mittel, um Speicherplatz zur Verfügung zu stellen, ist der Erwerb einer oder mehrerer Storage-Appliances, die Software und Hardware fest miteinander verzahnen. Allerdings sind diese nicht sehr flexibel, nicht skalierbar und lassen sich nicht so einfach zu Lösungen anderer Hersteller migrieren.
Anders sieht das beim Software-defined Storage (SDS) aus: Hier abstrahiert Software die Storage-Funktion der Hardware. Im Idealfall können verschiedene herkömmliche Server mit Festplatten oder SSDs zu einem Pool an Geräten zusammengeschaltet werden, wobei jedes System Speicherplatz bereitstellt und – je nach Lösung – unterschiedliche Aufgaben übernehmen kann. Skalierung ist möglich, indem weitere Geräte hinzugefügt werden, Flexibilität ist durch die Unabhängigkeit vom Hardwarehersteller und eine schnelle Reaktion auf wachsende Anforderungen gegeben. Im Normalfall sorgt die Software zudem dafür, dass Daten ausfallsicher über Server-Grenzen hinweg vorgehalten werden.
Große Auswahl und große Unterschiede
Im Open-Source-Bereich gibt es bereits einige Lösungen(öffnet im neuen Fenster) : Die bekanntesten sind Lustre, GlusterFS, Ceph und MooseFS. Nicht alle sind gleich gut, und einige haben sich spezialisiert, wie etwa Ceph auf Object Storage. Besonders gefragt ist das Feature, bei dem ein SDS ein Posix-kompatibles Dateisystem bereitstellt – aus Sicht des Clients soll das verteilte Dateisystem die gleichen Merkmale aufweisen wie ein gewöhnliches lokal verwendetes Dateisystem (beispielsweise Ext4).
Einige der verfügbaren Lösungen werden von großen Firmen betrieben, wie etwa Lustre, GlusterFS und Ceph. Andere hängen von wenigen Entwicklern ab oder werden gar überhaupt nicht mehr gepflegt, wie MooseFS. Das Projekt wirkt streckenweise wie tot oder auch wie ein Ein-Mann-Projekt ohne Langzeitstrategie und aktive Community. Diesen Umstand nahmen einige Entwickler aus Polen im Sommer 2013 zum Anlass, um einen Fork zu erstellen und ihn unter GLPLv3-Lizenz aktiv weiterzuentwickeln: LizardFS war geboren.
LizardFS wird von seinen Entwicklern als verteiltes skalierbares Dateisystem mit Enterprise-Features wie Fehlertoleranz, Ausfallsicherheit und Hochverfügbarkeit bezeichnet. Die Software wird hauptsächlich von rund zehn Entwicklern unter dem Dach der Warschauer Firma Skytechnology eigenständig entwickelt.
Wer LizardFS installieren möchte, kann die Software aus den Quellen bauen oder von der Download-Seite(öffnet im neuen Fenster) Pakete für Debian, Ubuntu, CentOS und Red Hat beziehen. Zudem gibt es LizardFS seit den vergangenen Monaten über diverse offizielle Distributionsquellen.
Komponenten und Architektur
Das Design von LizardFS sieht eine Trennung von Metadaten wie Dateinamen, Speicherorten und Prüfsummen von den eigentlichen Daten vor. Damit keine Inkonsistenzen entstehen und atomare Aktionen auf Dateisystemebene möglich sind, müssen sämtliche Vorgänge durch einen sogenannten Master geschleust werden. Er hält alle Metadaten vor und ist der zentrale Ansprechpartner für Server-Komponenten und Clients.
Damit ein Master ausfallen darf, kann er auch in einer "Shadow"-Rolle laufen. Hier wird ein Master auf einem zusätzlichen Server installiert, der aber passiv bleibt. Der Shadow-Master holt permanent alle Änderungen der Metadaten ab und spiegelt damit den Zustand des Dateisystems im eigenen Arbeitsspeicher. Fällt der Master aus, kann das zweite System mit dem Shadow-Master in die aktive Rolle hinüberschalten und weiter alle Teilnehmer mit Informationen versorgen.
Die Open-Source-Variante von LizardFS beinhaltet allerdings keinen automatischen Failover zwischen dem primären und theoretisch beliebig vielen sekundären Mastern. Als Administrator ist man daher entweder gezwungen, manuell umzuschalten oder eine eigene Failover-Mechanik zu bauen, etwa auf Grundlage eines Pacemaker-Clusters. Da das Umschalten der Master-Rollen jedoch nur aus dem Abändern einer Konfigurationsvariablen sowie einem Reload des Master-Daemons besteht, sollten Administratoren mit Erfahrung im Betrieb von Clustern schnell eine eigene Lösung finden können.
Verwaltet, gespeichert und repliziert wird über die Chunk-Server
Für die Verwaltung, das Speichern und die Replikation der eigentlichen Daten sind die sogenannten Chunk-Server verantwortlich. Wie alle anderen Komponenten auch, wird der Chunk-Server-Dienst auf einem beliebigen Linux-System installiert. Chunk-Server sollten im Idealfall über schnelle Speichermedien (wie SAS-HDs oder SSDs) verfügen und können ein Filesystem als Teil des Storage-Pools exportieren. Im kleinsten Fall läuft ein Chunk-Server in einer virtuellen Maschine und gibt beispielsweise ein 20 GB großes Ext4-Dateisystem frei.
Alle Chunk-Server sind untereinander verbunden und schließen ihre jeweils lokalen Dateisysteme zu einem Pool zusammen. Die Daten werden ab einer bestimmten Größe in einzelne Stripes aufgeteilt, erscheinen dann vor den Augen des Clients aber immer noch als eine Datei.
Der Metadata-Backup-Logger sammelt ähnlich wie ein Shadow-Master stets die Änderungen der Metadaten ein und sollte naturgemäß auf einem eigenen System laufen. Anders als ein typischer Master hält dieser die Metadaten jedoch nicht im Arbeitsspeicher, sondern lokal im Dateisystem vor. Im unwahrscheinlichen Fall eines Totalausfalls aller LizardFS-Master steht somit eine Sicherung für das Disaster-Recovery bereit.
Dateioperationen
Damit ein System von LizardFS exportierte Freigaben einhängen kann, muss das Paket Lizardfs-client installiert sein. Ein simples Kommando sorgt dafür, dass das System über einen Mount-Point, etwa unter /mnt, auf die Daten zugreifen kann, die auf den Chunk-Servern schlummern. Sobald der Benutzer oder eine Anwendung auf eine solche Datei zugreifen möchte, kontaktiert der installierte LizardFS-Client den aktuellen Master. Dieser soll eine Liste an Chunk-Servern zurückgeben, welche die gewünschte Datei beherbergen. Der Client nimmt die Liste in Empfang und kontaktiert im Anschluss einen der Chunk-Server, um eine Aufforderung zum Senden der Datei abzusetzen. Der Chunk-Server antwortet abschließend mit dem gewünschten Datenstrom.
Soll eine Datei auf dem LizardFS-Storage-Pool geschrieben oder verändert werden, muss der LizardFS-Client ebenfalls Rücksprache mit dem Master halten. Es könnte ja sein, dass eine bestehende Datei aufgrund von Balancing-Mechanismen verschoben wurde oder ein eben noch verfügbarer Chunk-Server offline gegangen ist. Erst wenn der Master einen Chunk-Server für den Schreibvorgang auswählt und an den Client übermittelt, sendet dieser im nächsten Schritt seine Daten an den Ziel-Chunk-Server.
Dieser bestätigt den Schreibvorgang und leitet, falls notwendig, eine Replikation der frisch geschriebenen Daten ein. Damit stellt der Chunk-Server sicher, dass ein gegebenenfalls gesetztes Replikationsziel möglichst zeitnah erfüllt wird. Eine Antwort an den LizardFS-Client signalisiert einen erfolgreichen Schreibvorgang. Der Client beendet daraufhin die soeben geöffnete Write-Session, indem der Master über den eben abgelaufenen Vorgang unterrichtet wird.
Sowohl beim Lese-, als auch beim Schreibvorgang achtet der LizardFS-Client auf eine möglicherweise konfigurierte Topologie. Wenn es dem Client sinnvoll erscheint, bevorzugt dieser ortsnahe Chunk-Server gegenüber jenen, die eventuell nur mit einer höheren Latenz erreichbar sind.
Simple, aber ausreichende Web-GUI
Damit Benutzer und Administratoren den Überblick behalten, stellt LizardFS mit dem CGI-Server eine simple, aber ausreichende Web-GUI bereit. Diese Komponente kann prinzipiell auf jedem System zusätzlich mit installiert werden und bietet eine Übersicht über alle Server im Verbund, die Anzahl der Dateien, deren Replikationszustände und andere wichtige Informationen.
Wer zudem einen Support-Vertrag mit der Firma hinter LizardFS abschließt, kann den proprietären uRaft-Daemon einsetzen. Dieses Tool ist unabhängig von LizardFS und bietet auf Grundlage des Raft-Consensus-Algorithmus(öffnet im neuen Fenster) eine Mechanik für den automatisierbaren Failover. Mit Hilfe von Heartbeats wählen alle beteiligten Master-Daemons stets einen Hauptverantwortlichen aus. Damit das zuverlässig funktioniert, sollte für ein Quorum eine ungerade Zahl an Mastern zur Verfügung stehen.
uRaft sorgt dann mit Hilfe von einfachen Shell-Scripten dafür, dass die Master jeweils befördert oder degradiert werden. Wer LizardFS zusammen mit dem uRaft-Daemon laufen lässt, gibt die typischen Master- und Shadow-Rollen auf und überlässt uRaft ganz die Verwaltung der einzelnen Rollen. Zudem sorgt uRaft für den Start und Stop der Master-Daemons, womit Administratoren das Init-Script für den LizardFS-Master nicht mehr verwenden dürfen.
uRaft setzt voraus, dass sich alle Master im gleichen Netz befinden und mit dem jeweils primären Master eine Floating-IP verschoben werden kann. Der uRaft-Daemon wird auf jedem Server installiert, auf dem auch ein Master-Dienst läuft.
Alle Komponenten stellen kaum Anforderungen an das darunter liegende System. Einzig der Master-Server sollte, je nach Anzahl der zu verwaltenden Dateien, über etwas mehr Arbeitsspeicher verfügen.
Feature-Vielfalt und Limits
LizardFS stellt aus Client-Sicht ein Posix-kompatibles Dateisystem zur Verfügung, das – ähnlich wie bei NFS – über einen Mount-Befehl eingehängt werden kann. Während die Server-Komponenten zwingend Linux als das zugrundeliegende Betriebssystem voraussetzen, können, neben Linux-basierten Clients, auch Windows-Rechner auf das Netzwerkdateisystem zugreifen.
Naturgemäß läuft LizardFS im Idealfall auf mehreren Servern, wobei es für die Funktionalität keine Rolle spielt, ob virtuelle Maschinen oder Standardhardware zum Einsatz kommen. Alle Server können sämtliche oder unterschiedliche Rollen einnehmen, wobei eine Spezialisierung teilweise sinnvoll ist. So sollten Chunk-Server eher auf Systemen mit viel (und gegebenenfalls schnellem) Speicherplatz laufen, während die Master-Server vor allem Anforderungen an CPU und Arbeitsspeicher stellen. Der Metadata-Backup-Logger hingegen kann wegen der niedrigen Anforderungen auch auf einer kleinen virtuellen Maschine oder einem Backup-Server mitlaufen.
Die Daten werden mit Hilfe vorgefertigter Replikationsziele ("Goals") beliebig oft zwischen den Systemen repliziert und liegen so redundant und gleichzeitig fehlertolerant vor – fällt ein Chunk-Server aus, sind die Daten dennoch über andere Server verfügbar. Ist das defekte System repariert und wieder im Verbund eingegliedert, übernimmt LizardFS automatisch die Neuverteilung der Dateien, damit die Replikationsziele wieder erfüllt werden können. Die Goals können standardmäßig auf Server-Seiten eingestellt werden; alternativ erlaubt man auch den Clients, Replikationsziele zu setzen. Damit ist es beispielsweise möglich, ein eingehängtes Dateisystem prinzipiell redundant vorzuhalten, aber dem Benutzer die Gelegenheit zu geben, zum Beispiel temporäre Dateien nur einmal im Storage-Pool abzulegen.
Die Chunk-Server können mit den Topologien aus dem eigenen Rechenzentrum gefüttert werden, womit LizardFS im Bilde ist, ob sich die Chunk-Server im gleichen Rack oder Cage befinden. Wer die Topologien sinnvoll konfiguriert, kann den durch die Replikation verursachten Traffic somit hinter dem gleichen Switch oder innerhalb einer Co-Location halten, da die Topologien auch an die Clients propagiert werden.
LizardFS über Rechenzentrumsgrenzen hinweg betreiben
Wer LizardFS über Rechenzentrumsgrenzen hinweg betreiben möchte, kann die Topologien auch als Grundlage für die Georeplikation verwenden und LizardFS zeigen, welche Chunk-Server sich in welchem Rechenzentrum befinden. Die Clients, die auf den Storage-Pool von LizardFS zugreifen, können somit dazu gebracht werden, RZ-lokale Chunk-Server gegenüber weit entfernten zu bevorzugen. Darüber hinaus müssen sich Anwender und Applikationen nicht um eine eigene Replikation bemühen. Wenn die Topologien korrekt konfiguriert sind, fällt die Georeplikation einfach hinten heraus und die Daten werden automatisch zwischen zwei oder mehreren Standorten synchronisiert.
Die von LizardFS bereitgestellten Freigaben können prinzipiell von allen Netzteilnehmern eingehängt werden. Wer diese Zugriffe beschränken möchte, kann sich jedoch beispielsweise auf einen Read-only-Export beschränken oder ACLs auf Grundlage von Netzbereichen und/oder IPs vergeben. Auch die Vergabe eines Kennworts ist möglich. Zum gegenwärtigen Zeitpunkt sind weitere Einschränkungen, zum Beispiel auf bestimmte Benutzergruppen, die womöglich aus einem LDAP oder Active Directory kommen, nicht vorgesehen.
Die Konfigurationsdatei für die LizardFS-Exports ist stark an die von NFS bekannte Datei /etc/exports angelehnt und akzeptiert teils auch von NFS bekannte Parameter.
LizardFS eignet sich zur Archivierung
Wer viele verschiedene Systeme oder User auf LizardFS-Volumes zugreifen lässt, kann Quota aktivieren und somit die Nutzung des Speicherplatzes einschränken. Da Benutzer von Samba und Windows-Freigaben den beliebten Mülleimer gewohnt sind, lässt sich ein solcher auch für LizardFS-Freigaben aktivieren. In den Mülleimer verschobene Dateien gelten dann erst einmal nicht als gelöscht und bleiben weiterhin auf den Chunk-Servern liegen, solange die konfigurierte Vorhaltezeit noch nicht überschritten wurde. Administratoren haben die Möglichkeit, LizardFS-Freigaben mit einem bestimmten Parameter einzuhängen, womit dann ein Zugriff auf die virtuellen Papierkörbe gelingt. Leider fehlt jedoch die Option, den Usern selbst Zugriff auf bereits gelöschte Daten zu geben.
Eine andere Möglichkeit, Dateien vorzuhalten, bieten die Snapshots. Es gibt ein Kommando, um eine Datei in einen Snapshot zu duplizieren. Diese Aktion ist besonders effizient – der Master-Server kopiert erst einmal nur die Metadaten. Erst wenn sich die frisch angelegte Datei vom Original unterscheidet, werden die entsprechenden Blöcke auf den Chunk-Servern modifiziert.
Um Dateien zu archivieren, eignet sich LizardFS übrigens auch – dank der Replikation-Goals und Topologien können Dateien so angelegt werden, dass eine Kopie von ihnen stets auf einem gewünschten oder einer Gruppe von Chunk-Servern landen. So ist es denkbar, dass eine Gruppe Chunk-Server über Tapes (LTO) als Speichermedien verfügen, da LizardFS diese nativ ansprechen kann. Falls gewünscht, kann LizardFS daher dafür sorgen, dass bestimmte Daten stets auf Tape vorgehalten werden und bei Bedarf davon gelesen werden können.
Für die Überwachung einer LizardFS-Umgebung steht eine bereits erwähnte Web-GUI zur Verfügung. Da diese aber ein klassisches Monitoring nicht ersetzen kann, bietet LizardFS bei nahezu allen administrativen Tools, die etwa die Abfrage von Zuständen erlauben, ein spezielles Ausgabeformat, das leicht von Checks ausgelesen werden kann. Einer Anbindung an Nagios oder andere Monitoring-Tools steht damit nichts im Wege. Dank der Abwärtskompatibilität zu einer älteren Version von MooseFS können zudem viele Module beziehungsweise Plugins verwendet werden, die sich im Internet zur Überwachung von MooseFS finden lassen. Findige Systembetreuer schreiben ihre eigenen Checks.
Mehr Chunk-Server für mehr Speicherplatz
Falls der Bedarf an Speicherplatz steigt, können weitere Chunk-Server hinzugefügt werden. Auch ist es möglich, bestehende Chunk-Server herauszunehmen, solange die darauf liegenden Daten auch anderweitig vorgehalten werden. Fällt ein Chunk-Server aus, sorgt LizardFS selbstständig für einen Re-Balance und bietet gerade zugreifenden Clients alternative Chunk-Server als Datenquellen an.
Analog zu den Chunk-Servern können übrigens auch Master-Server skalieren – genügen zwei Master etwa wegen der Standortanforderungen nicht mehr, können weitere einfach hinzugenommen werden.
Wenn Administratoren ihre Daten nicht nur ausfallsicher und fehlertolerant abspeichern, sondern auch vor neugierigen Augen schützen wollen, müssen zusätzliche Maßnahmen ergriffen werden. LizardFS teilt zwar Dateien unter Umständen in verschiedene Stripes auf. Das genügt aber den Anforderungen an Sicherheit und Datenschutz häufig nicht. Da von Haus aus keine Verschlüsselungsmechanik eingebaut ist, müssen LizardFS-Admins dafür Sorge tragen, dass die Ebene unter dem von Chunk-Servern exportierten Dateisystem verschlüsselt ist. Denkbar sind etwa der Einsatz von selbstverschlüsselnden Festplatten oder via LUKS verschlüsselten Dateisystem-Containern.
Anwendungsfälle
Da LizardFS dem "Client" die Daten wie ein klassisches Storage präsentiert, kann es prinzipiell überall eingesetzt werden, wo Speicherplatz benötigt wird. Sinnvoller ist allerdings ein Einsatz, wenn die Daten beispielsweise redundant vorgehalten werden sollen oder eine Alternative zu klassischen, teuren und unflexiblen Storage-Appliances benötigt wird.
Wer die Verwendung von LizardFS in Erwägung zieht, sollte allerdings bedenken, dass typischerweise mehrere Server zu einem großen Pool zusammengeschaltet werden. Dadurch kann nicht immer garantiert werden, dass zusammenhängende Daten, wie beispielsweise die einer Datenbank, auf einem einzelnen Chunk-Server abgespeichert werden. Der Administrator kann zwar durch Topologien Einfluss auf Speicherorte nehmen (zum Beispiel: eine Kopie im Rack 14, eine andere Kopie im Rack 15), aber dies stellt – je nach Einsatzszenario und Konfiguration von LizardFS – nicht unbedingt eine Garantie für feste Speicherorte dar.
Es ist also möglich, dass eine Anwendung ihre Daten über mehrere Chunk-Server (und damit gegebenenfalls über Rack- oder gar RZ-Grenzen hinweg) schreibt. Es gibt durchaus Situationen, in denen dann durch erhöhte Netzlatenzen Lese- und Schreibvorgänge verzögert werden. Je nach Anwendungsfall führt das zu längeren Antwortzeiten der eingesetzten Anwendung. Typischerweise vermeidet man es daher beispielsweise, große und stark frequentierte Datenbanken auf ein verteiltes Dateisystem schreiben zu lassen. Für die meisten anderen Anwendungsfälle hingegen ist LizardFS problemlos geeignet.
Auch als Storage-Pool für eine Render-Farm oder Mediendateien eignet sich LizardFS, da alle Clients gleichzeitig auf verschiedene Chunk-Server zugreifen und damit die Performance der einzelnen beteiligten Server ausreizen können. Weniger bekannt ist die Möglichkeit, LizardFS als Storage für virtuelle Maschinen einzusetzen. Skytechnology arbeitet eigenen Angaben zufolge auch an einer besseren Integration in VMWare, um LizardFS als Cloud-VM-Speicher interessanter zu machen.
Erfahrungswerte
Der Autor beschäftigt sich seit Längerem mit SDS-Technologien und testet eine LizardFS-Umgebung im Rahmen eines Pilotierungsprojekt. Der mehrere Monate andauernde Testlauf basiert auf der zum Startzeitpunkt für Debian 7 verfügbaren LizardFS-Version 2.6 und sieht die Überprüfung der Software unter produktionsnahen Bedingungen inklusive verschiedener Tests, unter anderem Failovers, vor.
Die hier beschriebenen Tests decken zwar nur einen Teil der möglichen Ereignisse ab, zeigen aber, dass die Lösung grundsätzlich funktioniert und mit Fehlerfällen umgehen kann. Das Verhalten von LizardFS in einem solchen Fall wirkt in der Regel nachvollziehbar, wenn auch manchmal etwas träge.
Eines der Testszenarien war der Neustart eines Masters, um einen Wechsel der Master-Rolle auf einen anderen Knoten in einem anderen Rechenzentrum zu provozieren. Der gleichzeitig stattfindende Lesezugriff eines Clients wurde während des Master-Wechsels für knapp zwei Sekunden unterbrochen, lief danach jedoch weiter. In solchen Fällen scheint es also wichtig, dass die zugreifende Applikation mit solchen Wartezeiten umgehen kann und der Master-Wechsel möglichst schnell erfolgt.
Ein anderes Szenario sieht vor, dass Clients die RZ-lokalen Chunk-Server kennen und sie beim Lesezugriff gegenüber den Chunk-Servern von einem anderen Standort bevorzugen. Während eines Lesevorgangs durch einen RZ-lokalen Client wurden die Chunk-Server im gleichen Standort vom Netz getrennt, womit der Client die Daten ohne erkennbare Verzögerung von den Chunk-Servern des anderen Standorts bezog. Sobald die vom Netz getrennten Chunk-Server im gleichen RZ wieder verfügbar waren, schwenkte der Client automatisch zurück und las die Daten wieder von den ursprünglichen Nodes.
Diese Tests haben ein Limit aufgezeigt: In LizardFS werden Goals festgelegt, die besagen, wie oft das verteilte Dateisystem eine Datei vorhalten soll. In der Regel stellt man mindestens genauso viele bis deutlich mehr Chunk-Server auf, damit dieses Ziel erfüllt werden kann. Wenn durch Tests, Reboots, Abstürze oder andere Ausfälle jedoch zu wenige Chunk-Server online sind, um das Ziel für eine neue Datei sofort zu erfüllen, verweigert der LizardFS-Master den Schreibvorgang. In diesem Beispiel waren nur noch zwei Chunk-Server bei einem Replication-Goal von drei verfügbar. Ein LizardFS-Entwickler bestätigte dieses Verhalten und kündigte eine interne Diskussion zu diesem Thema an.
Im Vergleich
LizardFS muss sich im SDS-Bereich mit vielen verschiedenen Konkurrenten messen, etwa mit Ceph oder GlusterFS. Ceph ist primär ein zu Amazons S3-API kompatibler Object-Store, kann aber auch Block-Devices oder ein Posix-kompatibles Dateisystem ("CephFS") bereitstellen. Letzteres ist mehr ein Overlay über den Object-Store als ein robustes Dateisystem. Die Hersteller schreiben selbst auf ihrer Webseite(öffnet im neuen Fenster) , dass sich CephFS derzeit primär an Early-Adopter richtet und keine wichtigen Daten darauf gespeichert werden sollten. Da Ceph seinen Fokus auf die Object-Store-Funktionalität legt, kann es nicht als direkte Konkurrenz zu LizardFS betrachtet werden.
GlusterFS bietet auf dem Papier die nahezu gleiche Funktionalität, ist aber schon länger auf dem Markt und genießt dementsprechend viel Ansehen in der SDS-Community. GlusterFS bietet viele verschiedene Betriebsmodi, die je nach Konfiguration verschiedene Level an Ausfallsicherheit und Performance bieten. Es bietet diese Konfigurationsmöglichkeiten auf Volume-Ebene, während LizardFS die Replikationsziele pro Ordner oder Datei festlegt. Beide Varianten besitzen ihre Vor- und Nachteile: Bei GlusterFS muss sich der Administrator bei Erstellung des Volumes für eine Variante entscheiden, während die Replikationsart bei LizardFS jederzeit abänderbar ist.
Für sicherheitsbewusste Systembetreuer bietet GlusterFS die Möglichkeit, ein Volume mit einem Key zu verschlüsseln. Nur die Server, die den richtigen Key vorweisen können, sind dann in der Lage, das Volume einzuhängen und zu entschlüsseln. Sowohl GlusterFS als auch LizardFS werden auf Linux-Clients als FUSE-Modul im User-Space betrieben.
Während bei LizardFS die Daten nur einmal auf einen Chunk-Server geschrieben werden müssen (von dort aus replizieren die Chunk-Server untereinander weiter), übernimmt bei GlusterFS der Client die Replikation: Der Schreibvorgang geschieht auf allen beteiligten GlusterFS-Servern parallel, sodass der Client sicherstellen muss, dass die Replikation überall erfolgreich abgeschlossen wurde. Das sorgt bei Schreibzugriffen für eine langsamere Performance, fällt aber ansonsten nicht ins Gewicht.
Während LizardFS dem Client stets einen Master präsentiert, können GlusterFS-Clients beim Einhängen des Volumens mehrere GlusterFS-Server angeben. Damit kann ein Client bei einem Ausfall des ersten angegebenen Servers auf andere GlusterFS-Nodes zurückgreifen.
Ausblick
Neben dem gewöhnlichen Beheben von Bugs und der Verbesserung von Performance und Stabilität sehen die Macher von LizardFS auch eine bessere Integration in VMWare vor. Anscheinend gibt es aber noch keine Pläne für die Integration einer Datenverschlüsselung, allerdings ist ein Protokoll-Rewrite geplant, der prinzipiell die Grundlage für neue Features wie Verschlüsselung bilden kann.
Um aktuelle Ceph-Nutzer gewinnen zu können, will LizardFS zudem in nicht genau datierter Zukunft ebenfalls eine S3-kompatible API bereitstellen. Langfristig soll es wohl möglich sein, LizardFS als Object-Store verwenden zu können. Unklar bleibt, bis wann LizardFS diese Funktionalität bieten soll. Für die Erschließung eines größeren Nutzerkreises sei auch eine SPARC-Portierung geplant.
Weitere kleinere Verbesserungen sollen erweiterte ACLs, Order-basierte Quota, besseres Logging-Verhalten bei Windows-Clients und Minimal-Goal-Settings enthalten. Letzteres wird schon lange von der Community gewünscht und soll für mehr Zuverlässigkeit und Datensicherheit sorgen.
Fazit
LizardFS positioniert sich als Alternative zu GlusterFS und wird schon jetzt in Setups mit mehreren Hundert Terabyte als SDS-Lösung betrieben. Das Projekt bietet viele interessante Features und dürfte den meisten Ansprüchen genügen. Zudem kann es Daten auch zwischen mehreren Rechenzentren synchron halten. Eine Alternative zu Ceph ist es nicht, da LizardFS keinen Object-Store bereitstellen kann.
Verbesserungsbedarf gibt es bei der Kommunikation nach außen (Roadmap, Dokumentation, Community-Arbeit), der Software-Versionierung – kleine Versionswechsel markieren schon mal ein Major-Release – und im technischen Detail: Ein SDS sollte schon heute eine native Verschlüsselung für Kommunikation zwischen den Nodes und Daten mitbringen und dafür Sorge tragen, dass Schreibvorgänge auch dann möglich sind, wenn viele Chunk-Server offline sind.
Schade ist, dass die Firma hinter LizardFS den Daemon für automatische Failovers zahlenden Kunden vorbehält und der Community kein Äquivalent zur Verfügung stellt. Es gibt zwar Hinweise in der Community, wie ein Pacemaker-Cluster für automatisierten Failover sorgen kann. Hier fehlt es aber an klaren Anleitungen, Scripten und Empfehlungen seitens der LizardFS-Macher.
Für alle, die eine Alternative zu GlusterFS oder schlicht ein funktionierendes SDS suchen, dürfte LizardFS jedoch interessant sein. Die Zukunft wird zeigen, wie ernst es die Entwickler mit ihren Ankündigungen meinen, etwa bezüglich der Implementierung einer S3-kompatiblen API, und ob zehn aktive Entwickler ein Projekt mit solchen Ambitionen langfristig stemmen können.
Über den Autor
Valentin Höbel arbeitet als Cloud Architect für die NFON AG aus München. In seiner Freizeit beschäftigt er sich mit Open-Source-Technologien und berichtet in Online- und Printmedien von seinen Erfahrungen. Seit kurzem hilft er unentgeltlich beim Aufbau eines Community-Forums für LizardFS, um anderen Nutzern den Austausch zu diesem Projekt zu vereinfachen.
Blog: http://www.xenuser.org
Twitter: https://twitter.com/xenuser
- Anzeige Hier geht es zu Hacking & Security: Das umfassende Handbuch bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.