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

Objektorientierung bei GlusterFS

Bis einschließlich Version 3.2 war GlusterFS eine Datei-basierte Storage-Lösung. Ein objektorientierter Ansatz war nicht vorhanden. Die Popularität von Amazon S3 und anderen Object-Store-Lösungen "zwang" die Entwickler zum Handeln. Mit 3.3 kam dann UFO – Unified File and Object (Store). GlusterFS orientiert sich hier sehr stark an der von OpenStack bekannten Swift-API. Die Integration in die Open-Source-Cloud-Lösung ist auch mit riesigem Abstand der meistbenutzte Anwendungsfall. Es sieht auch nicht so aus, als ob sich das in absehbarer Zeit ändert. Version 3.4 ersetzte dann UFO durch G4O (GlusterFS fo(u)r OpenStack) und brauchte eine verbesserte RESTful-API. Verbesserung bezieht sich in diesem Fall hauptsächlich auf die Kompatibilität zu Swift. Schade, eine weit weniger spezialisierte Schnittstelle könnte andere Software-Projekte "anlocken". Blickt man übrigens hinter die Kulissen, so arbeitet GlusterFS immer noch auf der Basis von Dateien. Technisch besteht das Backend für UFO/G4O aus zusätzlichen Verzeichnissen und Hardlinks (Listing 2).

Listing 2

Hinter den Kulissen der Gluster-Objekte

 

GlusterFS tritt hier als Hybrid auf und weist jeder Datei ein Objekt zu und umgekehrt. Die Objekte verwaltet die Software im Verzeichnis ».glusterfs« . Aus der GFID (GlusterFS File ID) generiert die Storage-Software eine recht flache Verzeichnisstruktur und legt dort Hardlinks zwischen Objekt und Datei an. Die aus der Swift-Welt bekannten Objekte, Container und Accounts entsprechen Dateien, Verzeichnissen und Volumes auf der GlusterFS-Seite.

Tuning für GlusterFS und Ceph

Um das Beste aus GlusterFS herauszuholen, kann der Admin an verschiedenen Stellen ansetzen. Von der reinen Physik her ist der Netzwerkdurchsatz und die Schnelligkeit der Platten hinter dem Brick bestimmend. Auf dieser Ebene ist das für GlusterFS vollkommen transparent. Es benutzt ein »eth0« genauso wie ein »bond0« . Schnellere Platten im Backend helfen. Zudem kann der Admin das korrespondierende Dateisystem tunen. Dabei hilft es, dass GlusterFS die ihm anvertrauten Dateien 1:1 im Backend ablegt. Es empfiehlt sich die Anzahl der Bricks pro Server nicht zu hoch zu wählen. Aber auch auf Protokollebene gibt es einiges einzustellen. Das Ein- oder Abschalten von »O_DIRECT« über den POSIX-Translator wurde schon weiter oben erwähnt. Auf Volume-Ebene lassen sich Lese-Cache und Schreibpuffer an die eigenen Wünsche anpassen. Relativ neu ist der Schalter »eager-lock« . Hier erlaubt GlusterFS eine schnellere Übergabe von Locks von einer Transaktion an die nächste. Generell gilt: Die relative Perfomance wächst mit Client-Anzahl. Die Verteilung auf Anwendungsebene kommen ebenfalls der GlusterFS-Leistung zugute. Single-threaded Applikationen sollte man meiden. Ceph bietet Administratoren im Hinblick auf die genutzte Hardware eines Speicher-Clusters einige interessante Optionen. Der zuvor schon beschriebene Prozess des Speicherns von Daten auf OSDs passiert im ersten Schritt zwischen dem Client und einem einzelnen OSD, das die binären Objekte vom Client entgegennimmt. Der Clou ist, dass auf der Seite des Clients mehr als eine Verbindung zu einem OSD zeitgleich gar kein Problem darstellt. Der Client kann also eine 16 Megabyte große Datei in vier Objekte zu vier Megabyte aufteilen und diese vier Objekte dann gleichzeitig auf unterschiedliche OSDs hochladen. Damit schreibt ein Client in Ceph stets auf mehrere Spindeln gleichzeitig, bündelt also – ähnlich wie in einem RAID0 – die Performance aller genutzten Platten.

Die Auswirkungen sind dramatisch: Anstelle von teuren SAS-Platten, wie sie in SAN-Storages zum Einsatz kommen, liefert Ceph mit normalen SATA-Platten vergleichbare Performance-Werte. Und letztere haben ein viel besseres Preis-Leistungs-Verhältnis. Lediglich die Latenz gibt manchem Admin Grund zur Sorge, weil die Latenz von SATA-Platten (gerade dann, wenn es sich um Desktop-Modelle handelt) hinter der Latenz ähnlicher SAS-Platten deutlich hinterherhinkt. Auch für dieses Problem haben die Ceph-Entwickler allerdings eine Lösung parat, die die Journale der OSDs betrifft.

In Ceph hat jedes OSD ein Journal, also einen vorgelagerten Bereich, der sämtliche Änderungen zunächst aufnimmt und sie danach letztendlich auf den eigentlichen Datenträger befördert. Das Journal kann entweder direkt auf den OSDs liegen oder auf einem externen Device, zum Beispiel einer SSD. Bis zu vier OSD-Journale lassen sich sinnvoll auf eine einzelne SSD auslagern, mit wiederum heftigen Auswirkungen auf die Performance: Clients beschreiben den Ceph-Cluster nämlich in solchen Setups mit der Geschwindigkeit, die mehrere SSDs gleichzeitig liefern, sodass eine solche Kombi sogar SAS-Platten im Hinblick auf die Performance hinter sich lässt.

Ä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

Ausgabe /2021