Nach einer einjĂ€hrigen Ruhephase in der Entwicklung die Arbeit an der neuen Version des fehlertoleranten verteilten Dateisystems und der zweite Kandidat fĂŒr die Releases. Vor kurzem gab es einen EigentĂŒmerwechsel bei der Firma, die LizardFS entwickelt. Es wurde eine neue Leitung ernannt und die Entwickler haben gewechselt. In den letzten zwei Jahren hatte das Projekt keinen Kontakt zur Community und schenkte ihr nicht die nötige Aufmerksamkeit, doch das neue Team plant, die frĂŒheren Beziehungen zur Community wiederzubeleben und eine enge Zusammenarbeit zu etablieren. Der Code des Projekts ist in C und C++ geschrieben und unter der GPLv3-Lizenz.
LizardFS ist ein verteiltes Cluster-Dateisystem, das es ermöglicht, Daten ĂŒber verschiedene Server zu verteilen und dennoch den Zugriff in Form eines einzelnen groĂen Volumes zu prĂ€sentieren, dessen Verwaltung analog zu traditionellen Festplattenschnittstellen erfolgt. Im eingehĂ€ngten Volume mit LizardFS werden POSIX-Dateiattribute, ACLs, Sperren, Sockets, Pipes, GerĂ€tedateien sowie symbolische und harte Links unterstĂŒtzt. Das System hat keinen einzelnen Punkt des Ausfalls, alle Komponenten werden redundant gehalten. Es wird die ParallelitĂ€t bei Datenoperationen unterstĂŒtzt (mehrere Clients können gleichzeitig auf Dateien zugreifen).
Zur GewĂ€hrleistung der Fehlertoleranz werden Daten in Repliken aufgeteilt, die ĂŒber verschiedene Knoten verteilt werden, wobei Redundanzen bestehen (mehrere Kopien auf unterschiedlichen Knoten platziert werden) â im Falle eines Ausfalls von Knoten oder Speichern lĂ€uft das System weiterhin ohne Informationsverlust und verteilt die Daten automatisch unter BerĂŒcksichtigung der verbleibenden Knoten neu. FĂŒr die Erweiterung des Speichers reicht es aus, neue Knoten anzuschlieĂen, ohne den Betrieb fĂŒr Wartungsarbeiten zu stoppen (das System repliziert selbst Teile der Daten auf neue Server und balanciert den Speicher unter BerĂŒcksichtigung der neuen Server). Ăhnlich kann auch die ClustergröĂe reduziert werden â es kann einfach veraltete Hardware, die nicht mehr benötigt wird, abgezogen werden.
Daten und Metadaten werden getrennt gespeichert. FĂŒr den Betrieb wird empfohlen, zwei Metadatenserver im Master-Slave-Modus sowie mindestens zwei Datenspeicherserver (Chunkserver) einzurichten. ZusĂ€tzlich können zur Sicherung der Metadaten Log-Server eingesetzt werden, die Informationen ĂŒber Ănderungen der Metadaten speichern und die Wiederherstellung im Falle einer BeschĂ€digung aller verfĂŒgbaren Metadatenserver ermöglichen. Jede Datei wird in Blöcke (Chunks) von bis zu 64 MB unterteilt. Die Blöcke werden entsprechend dem gewĂ€hlten Replikationsmodus auf den Speicherservern verteilt: Standard (explizite Festlegung der Anzahl der Kopien fĂŒr die Verteilung auf verschiedene Knoten, wobei fĂŒr wichtige Daten die Anzahl der Kopien erhöht und fĂŒr unwichtige verringert werden kann), XOR (RAID5) und EC (RAID6).
Der Speicher kann auf Petabyte-GröĂen skalieren. Zu den Anwendungsbereichen gehören die Archivierung, Speicherung von Abbilden virtueller Maschinen, Multimedia-Daten, Backups sowie die Nutzung als DRC (Disaster Recovery Center) und als Speicher in Clustern fĂŒr Hochleistungsrechner. LizardFS gewĂ€hrleistet eine sehr hohe Lesegeschwindigkeit fĂŒr Dateien jeder GröĂe und zeigt beim Schreiben eine gute Leistung beim Schreiben ganzer groĂer und mittlerer Dateien, wenn keine stĂ€ndige Modifikation, intensive Arbeiten mit offenen Dateien und sporadische VorgĂ€nge mit vielen kleinen Dateien stattfinden.
Zu den Funktionen des FS gehört auch die UnterstĂŒtzung von Snapshots, die den Zustand von Dateien zu einem bestimmten Zeitpunkt widerspiegeln, sowie die integrierte Implementierung eines "Papierkorbs" (Dateien werden nicht sofort gelöscht und sind eine Zeit lang fĂŒr die Wiederherstellung verfĂŒgbar). Der Zugriff auf den Bereich kann nach IP-Adresse oder Passwort eingeschrĂ€nkt werden (analog zu NFS). Es gibt Quoten- und QualitĂ€tssicherungsmechanismen, die es ermöglichen, die GröĂe und Bandbreite fĂŒr bestimmte Benutzergruppen zu begrenzen. Es ist möglich, geografisch verteilte Speicher zu erstellen, deren Segmente in verschiedenen Rechenzentren untergebracht sind.
Das Projekt LizardFS wurde 2013 als Fork gegrĂŒndet. , und unterscheidet sich hauptsĂ€chlich durch das Vorhandensein eines Replikationsmodus auf der Grundlage von Reed-Solomon-Fehlerkorrekturcodes (analog zu raidzN), erweiterte UnterstĂŒtzung fĂŒr ACL, einen Client fĂŒr die Windows-Plattform, zusĂ€tzliche Optimierungen (zum Beispiel werden bei der Kombination von Client und Speicherserver die Blöcke nach Möglichkeit vom aktuellen Knoten bereitgestellt und die Metadaten im Speicher zwischengespeichert), ein flexibleres Einstellsystem, UnterstĂŒtzung fĂŒr vorzeitiges Lesen von Daten, Quoten fĂŒr Verzeichnisse und interne Ăberarbeitungen.
Die Veröffentlichung von LizardFS 3.13.0 ist fĂŒr Ende Dezember geplant. Die Hauptneuheit von LizardFS 3.13 ist die Verwendung eines Konsensalgorithmus zur GewĂ€hrleistung der Ausfallsicherheit (Umschaltung von Master-Servern im Falle eines Ausfalls). (es wird eine proprietĂ€re Implementierung von uRaft verwendet, die zuvor in kommerziellen Produkten eingesetzt wurde). Die Verwendung von uRaft vereinfacht die Konfiguration und reduziert die Latenz beim Wiederherstellen nach einem Ausfall, erfordert jedoch mindestens drei funktionierende Knoten, von denen einer fĂŒr das Quorum verwendet wird.
Zu den weiteren Ănderungen gehören: ein neuer Client auf Basis des FUSE3-Subsystems, die Lösung von Fehlerkorrekturproblemen, das Plugin nfs-ganesha wurde in C neu geschrieben. In dem Update 3.13.0-rc2 wurden mehrere kritische Fehler behoben, die die vorherigen Testversionen des Zweigs 3.13 unbrauchbar machten (Korrekturen fĂŒr den Zweig 3.12 wurden noch nicht veröffentlicht, und ein Update von 3.12 auf 3.13 fĂŒhrt weiterhin zu einem vollstĂ€ndigen Datenverlust).
Im Jahr 2020 wird die Arbeit auf die Entwicklung
, eines neuen, vollstĂ€ndig neu geschriebenen Kerns von LizardFS konzentriert, der laut den Entwicklern eine dreifache Leistungssteigerung im Vergleich zum Zweig 3.12 bieten wird. In Agama wird der Ăbergang zu einer ereignisgesteuerten Architektur (event driven) sowie asynchroner Ein- / Ausgabe auf der Basis von , ĂŒberwiegend im Benutzerspeicher stattfinden (um die AbhĂ€ngigkeit von den Caching-Mechanismen des Kernels zu verringern). ZusĂ€tzlich werden ein neues Debugging-Subsystem und ein Analysewerkzeug fĂŒr die NetzwerkaktivitĂ€t mit UnterstĂŒtzung fĂŒr die automatische Leistungsoptimierung angeboten.
Im LizardFS-Client wird umfassende UnterstĂŒtzung fĂŒr die Versionsverwaltung von Schreiboperationen hinzugefĂŒgt, was die ZuverlĂ€ssigkeit der Wiederherstellung nach einem Ausfall verbessert, Probleme löst, die beim gleichzeitigen Zugriff verschiedener Clients auf dieselben Daten auftreten, und eine erhebliche Steigerung der Leistung ermöglicht. Der Client wird auf ein eigenes NetzwerkSubsystem umgestellt, das im Benutzerspeicher arbeitet. Der erste funktionale Prototyp von LizardFS auf Basis von Agama soll im zweiten Quartal 2020 fertiggestellt werden. Gleichzeitig wird versprochen, Mittel zur Integration von LizardFS mit der Kubernetes-Plattform bereitzustellen.
Quelle: opennet.ru
