Das Titelthema im ADMIN 04/14 "Vernetzt speichern" sind Netzwerkdateisysteme, etwa Samba 4, verteilter Storage mit Ceph & GlusterFS und der Unix-Klassiker ... (mehr)

Lizenzgeschäfte

Im Hinblick auf die genutzte Lizenz gibt es bei Ceph nicht sonderlich viel zu sagen: Das Projekt setzt durchgehend auf die LGPL, also die Variante der GPL, bei der auch die Verlinkung in eine nicht freie Software erlaubt ist, solange anschließend nicht aus den beiden verlinkten Teilen ein ganz neues Werk wird (Derivative Work). Aus Inktank-Sicht ist das eine sinnvolle Entscheidung, schließlich ist es durchaus denkbar, dass man in absehbarer Zeit Ceph auch als Bestandteil kommerzieller Storage-Produkte ins Rennen schickt, und in einem solchen Szenario wäre die Beschränkung der GPL [3] im Hinblick auf verlinkte Software eher lästig.

Die LGPL gilt übrigens für alle Komponenten, die Teil von Ceph sind. Dazu gehören die OSDs und MONs genauso wie die Metadaten-Server für das Dateisystem CephFS und die genutzten Bibliotheken, also Librados und die RBD-Bibliothek Librbd.

GlusterFS stand bis zur Übernahme durch Red Hat im Jahre 2011 unter der GNU Affero General Public License (AGPL, [4]). Außerdem mussten die Mitentwickler eine Zuarbeitungsvereinbarung (Contributor License Agreement, CLA, [5]) unterzeichnen. Dies ist nicht unbedingt unüblich in der Open-Source-Gemeinde und dient zum Schutz des Schirmherren des Software-Projektes. Red Hat entfernte die Notwendigkeit der eben genannten Zuarbeitungsvereinbarung und stellte GlusterFS unter die GNU Public License Version 3 (GPLv3). Der neue "Besitzer" der Open-Source-Storage-Software wollte und will damit möglichst große Offenheit zeigen. Die Lizenzänderung war Teil der Diskussionen in der Zeit der Übernahme von Gluster Inc. durch Red Hat. Es ist davon auszugehen, dass in der nächsten Zukunft keine weitere Anpassung in dem Bereich ansteht.

Frontends – erste Klappe

Für den POSIX-ähnlichen Zugriff auf Daten im GlusterFS-Verbund bringt die Software gleich zwei verschiedene Möglichkeiten mit. Ein offensichtlicher Ansatz ist natürlich ein Dateisystemtreiber. Für lokale Datenträger oder auch traditionelle verteilte Lösungen ist dieser Treiber meistens Teil des Linux-Kernels. In der jüngeren Vergangenheit erfreuen sich aber auch sogenannte Dateisysteme im Userspace (File system in USEr Space – FUSE, [6], Abbildung 2) recht großer Beliebtheit. GlusterFS nutzte ebenfalls diesen Ansatz. Das hat gleich mehrere Vorteile: Die Entwicklung unterliegt nicht den strengen Regularien des Linux-Kernels. Die Portierung auf andere Plattfromen ist einfacher  – wenn man voraussetzt, dass diese ebenfalls FUSE unterstützen. Außerdem läuft damit der gesamte Software-Stack im Userspace. Die üblichen Mechanismen zur Prozessverwaltung sind damit eins zu eins anwendbar.

Abbildung 2: GlusterFS nutzt FUSE für den nativen Zugriff über eine POSIX-kompatible Schicht.

Allerdings ist FUSE als Ansatz nicht unumstritten. Die zusätzlichen Kontextwechsel zwischen Kernel- und User-Land beeinträchtigen auf jeden Fall die Performance des Dateisystems.

Interessanterweise bringt GlusterFS einen eigenen NFS-Server [7] mit. Auf den zweiten Blick ist das nicht unbedingt verwunderlich. Erstens war NAS das Marktsegment, das GlusterFS erobern wollte. Zweitens sollten alle Funktionen Teil der Software sein und damit weitgehend unabhängig vom darunterliegenden Betriebssystem und seiner Konfiguration. Dieser Ansatz der Eigenentwicklung hat aber auch seinen Preis. GlusterFS zahlt diesen primär dadurch, dass der eigene NFS-Server recht eingeschränkt ist. Version 4 [8] des Protokolls sucht man hier vergebens. Das Gleiche gilt für die Unterstützung von UDP. Der fehlende Network Lock Manager (NLM) ist inzwischen dabei (siehe Listing 1). Natürlich fehlt auch nicht die obligatorische RESTful-Schnittstelle. Jüngste der Zugriffsmöglichkeiten ist die Bibliothek »libgfapi« . So ausgestattet möchte GlusterFS die Storage-Welt erobern. Ob das reicht – das wird sich zeigen.

Listing 1

Gluster-NFS

 

Mit den oben genannten Einschränkungen kann der normale Linux-NFS-Client auf die Daten im GlusterFS-Verbund zugreifen. Ein separates Software-Paket ist nicht nötig. Dies erleichtert die Migration von herkömmlichen NAS-Umgebungen, da der Löwenanteil der Arbeit quasi auf dem Server stattfindet.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019