CleanPress

Schlagwort: Stratis

  • Fedora 33 soll mit Stratis 2.1.0 ausgeliefert werden

    Fedora 33 soll mit Stratis 2.1.0 ausgeliefert werden

    Erst letzte Woche hatte das Fedora-Steuerungskomitee beschlossen, dass mit Fedora 33 Btrfs das neue Standard-Dateisystem für die Desktop-Varianten der Distribution sein wird. Jetzt wurde ein weiterer recht später Vorschlag unterbreitet, Stratis 2.1.0 mit Fedora 33 auszuliefern.

    Red Hats eigene Storage-Lösung

    Der zeitliche Zusammenhang lässt darauf schließen, das Red Hat darauf drängt, das dort favorisierte Storage-System Stratis 2.1.0 ebenfalls mit auszuliefern. Da Btrfs bei Fedora nur den Desktop betrifft, können sich die Varianten Server, IoT und andere die erweiterten Möglichkeiten von Stratis 2.1.0 zugute machen. Red Hat hatte sich 2017 von Btrfs abgewandt und die Entwicklung von Stratis begonnen.

    Gut integrierte Lösung

    Stratis soll die Eigenschaften von ZFS und Btrfs mit Blick auf künftige Anforderungen an Storage abbilden. Dabei will Red Hat aber kein neues Dateisystem schreiben, sondern unter Verwendung von XFS eine Anwendung bauen, die Anwendern mit unterschiedlichsten Storage-Anforderungen eine gut integrierte Lösung mit konsistenter Konfiguration bietet.

    In Rust und Python umgesetzt

    Hauptentwickler Andy Grover beschrieb es in einem Strategiepapier als eine Kommandozeilenlösung mit einer umfassenden API, die auf bestehenden Techniken aufbaut. Stratis wird in Rust und Python umgesetzt. Die eingesetzten Komponenten sind das Dateisystem XFS als Grundlage und Device-Mapper als Schnittstelle zur Erzeugung virtueller blockorientierter Geräte.

    Verschlüsselung per Pool

    Stratis 2.1.0 bietet Verschlüsselung auf der Ebene von Pools auf der Basis von LUKS2, führt neue D-Bus-Schnittstellen ein und baut stratis-cli weiter aus. Die Verschlüsselung eines Pools schließt alle darin eingebundenen Geräte ein. Pools werden mithilfe eines Schlüssels im Kernel-Schlüsselring verschlüsselt. Jeder verschlüsselte Pool kann einen anderen Schlüssel verwenden, aber alle Geräte in einem Pool werden mit einem einzigen Schlüssel verschlüsselt.

    Nur für neue Pools

    Anwender werden die neue Verschlüsselungsmethode nur wahrnehmen, wenn sie einen neuen Pool aufsetzen. Für bestehende Dateisysteme ändert sich nichts. Ein Tutorial auf der Webseite von Red Hat, führt in die Verwendung von Stratis ein, beinhaltet aber noch nicht die neuen Möglichkeiten der Verschlüsselung mit Stratis 2.1.0.

    Prall gefülltes Release

    Das für den 20. Oktober zur Veröffentlichung anstehende Fedora 33 schickt sich an, eine der Veröffentlichungen mit den meisten Änderungen der letzten Jahre zu werden, sowohl was die Zahlen als auch die Bedeutung der Änderungen angeht.

  • Fedora berät über Btrfs als Standard-Dateisystem

    Fedora 33

    Seit einigen Tagen wird auf der Fedora Mailingliste ein Vorschlag diskutiert, mit dem für den Herbst erwarteten Fedora 33 Btrfs anstatt Ext4 als Standard-Dateisystem für die Fedora Workstation auszuliefern. Der Vorschlag wird nicht nur von langjährigen Fedora-Entwicklern wie Neil Gupta unterstützt, sondern auch von Btrfs-Maintainer Josef Bacik, der bei Facebook mit für Btrfs verantwortlich ist.

    Besser als sein Ruf

    Btrfs hat über die Jahre einen schlechten Ruf erworben. Es gab viele Probleme, die teils sogar mit Datenverlust einhergingen. Auch die fehlenden oder qualitativ schlechten Tools zur Problemanalyse und -behebung standen in der Kritik. Damit hat die einst als das kommende neue Standard-Dateisystem für Linux gehandelte Software viel von ihrem Renommee verloren.

    Seit Jahren im Einsatz

    Andererseits setzen openSUSE und SUSE das Dateisystem seit 2014 als Standard ein. Bei Facebook laufen Millionen Server mit einfachen Consumer-SSDs auf Btrfs. NAS-Distributionen wie Rockstor oder die Software von NAS-Hersteller Synology und einiger anderer setzen ebenfalls darauf.

    Ist der Ruf erst ruiniert…

    Eines der Probleme von Btrfs heute ist, dass ein angekratzter Ruf schwer zu revidieren ist, da helfen die gebetsmühlenartig wiederholten Berichte aus der Vergangenheit nicht. Dabei ist das Dateisystem laut Meinung vieler Entwickler heute um einiges besser als sein Ruf. Lediglich bei RAID5/6 gibt es noch Probleme, die aber zum Teil auch an der Implementierung dieses RAID-Levels liegen.

    Btrfs hat gegenüber dem derzeit bei Fedora genutzten Standard LVM + ext4 unbestreitbare Vorteile, allen voran native Subvolumes, Crc32c-gestützte Checksummen, transparente Kompression, Deduplikation und Resizing. Hinzu kommen Snapshots, die auf einzelne Subvolumes begrenzt werden können.

    Erster Versuch

    Fedora und Red Hat haben eine wechselvolle Geschichte, wenn es um das Next-Gen-Dateisystem geht. Bereits 2011 sollte Btrfs mit Fedora 16 zum Standard werden, jedoch fand dies auch mit den Ausgaben 17 und 18 keine Mehrheit in Fedoras Steuerungskomitee FESCo.

    Bei Red Hat wurde das unter RHEL 6 als technische Vorschau eingeführte Dateisystem Btrfs nicht in RHEL 7 übernommen, sondern von XFS ersetzt. Gleichzeitig startete Red Hat auf dessen Basis die Entwicklung von Stratis als neuem Storage-System.

    Als Gründe für den Umstieg gab Red Hat den berüchtigten »out of disk space« Fehler an, der es bereits in die offizielle FAQ geschafft hatte, sowie Probleme mit den Balance Filtern für Metadaten. Zudem soll OverlayFS nach einer Auswertung bei Red Hat schneller beim Erstellen und Entfernen von Docker-Containern sein als Btrfs.

    Kein Entwickler an Bord

    Red Hats Entscheidung ist nachvollziehbar, wenn man weiß, dass mit Josef Bacik bereits 2012 der einzige Btrfs-Entwickler auf Red Hats Besoldungsliste das Unternehmen verließ, um 2013 zusammen mit Btrfs-Vater Chris Mason bei Facebook anzuheuern, wo seitdem der Schwerpunkt der Weiterentwicklung liegt.

    Die Diskussion bei Fedora beginnt gerade erst und es wird spannend zu sehen, ob Fedora diesen Schritt für das im Oktober erwartete Fedora 33 geht, obwohl Red Hat Btrfs 2017 den Laufpass gegeben hat.

  • Red Hat Storage Stratis 2.1

    Stratis 2.1
    Bild: No [Storage] Zone | Quelle: that jon jackson | Lizenz: CC BY 2.0

    Als Red Hat sich 2017 von Btrfs als Dateisystem abwendete, bekam das für seine hohe Geschwindigkeit bekannte XFS eine Chance, sich zu beweisen. Aber ihm fehlten Funktionen, die Btrfs für Red Hat interessant gemacht hatten. Seitdem baut Red Hat an einer neuen Datenträgerverwaltung die gerade in Version Stratis 2.1 veröffentlicht wurde.

    Lernen von ZFS und Btrfs

    Stratis soll die Eigenschaften von ZFS und Btrfs mit Blick auf künftige Anforderungen an Storage abbilden. Dabei will Red Hat aber kein neues Dateisystem schreiben, sondern aus bestehenden Komponenten eine Anwendung bauen, die Anwendern mit unterschiedlichsten Storage-Anforderungen eine gut integrierte Lösung mit konsistenter Konfiguration bietet.

    DeviceMapper als Schnittstelle

    Hauptentwickler Andy Grover beschrieb es in einem Papier als eine Kommandozeilenlösung mit einer umfassenden API, die auf bestehenden Techniken aufbaut. Stratis wird in Rust und Python umgesetzt. Die eingesetzten Komponenten sind das Dateisystem XFS als Grundlage und Device-Mapper als Schnittstelle zur Erzeugung virtueller blockorientierter Geräte.

    Stratis 2.1 mit Verschlüsselung

    XFS wird von Red Hat in der Entwicklung gefördert und beherrscht seit Stratis 1.0, das erstmals mit Fedora 29 ausgeliefert wurde, Funktionen wie Snapshots, Storage-Pools und Copy-on-Write (COW). Mit der jetzt erschienenen Version Stratis 2.1 bietet der Daemon Unterstützung für Verschlüsselung auf der Basis von LUKS2.

    Benutzbar, aber nicht fertig

    Stratis 2.1 erhielt zudem verschiedene Änderungen an der D-Bus-Schnittstelle, eine neue Schnittstelle für JSON-formatierte Berichte, eine Überarbeitung des Codes für die Geräteidentifikation und -initialisierung und andere Code-Verbesserungen.

    Wann Stratis »fertig« sein wird, ist unklar, Dateisysteme stellen Entwickler oft vor schwierige Probleme. So dauerte es bis zur ersten nutzbaren Version von ZFS in 2001 rund vier Jahre. Btrfs wird seit rund 12 Jahren entwickelt und ist in Teilen immer noch instabil.

  • Red Hat Enterprise Linux 8 Beta zum Test bereit

    Red Hat Enterprise Linux 8 Beta
    Bild: Red Hat Linux | Quelle: Leonid Mamchenkov | Lizenz: CC BY 2.0

     

    Rund zwei Wochen nach dem Erscheinen des sechsten Updates für das aktuelle Red Hat Enterprise Linux 7 und dem Übernahmeangebot von IBM veröffentlicht das Unternehmen aus Raleigh in North Carolina die erste Beta-Version zu seiner Unternehmens-Distribution Red Hat Enterprise Linux 8 (RHEL 8). Die im nächsten Jahr in stabiler Version zu erwartende neue Version von RHEL modernisiert die Distribution an vielen Stellen und greift dabei unter anderem auf Techniken aus dem aktuellen Fedora 29 zurück.

    Modularisiert

    So führt RHEL 8 Beta die Modularisierung durch Application-Streams ein. Das ermöglicht dem Anwender, Entwicklungswerkzeuge und andere für Unternehmen relevante Software in verschiedenen Versionen zu installieren, ohne dabei das Basissystem zu aktualisieren. So können neben der aktuellen, mit der Distribution ausgelieferten Version auch ältere oder aktuellere Versionen genutzt werden.

    Storage-Pools vereinfacht

    Ebenfalls erstmals mit Fedora 29 veröffentlicht wurde die neue Storage-Lösung Stratis, die sich bereits in der Beta zu RHEL 8 wiederfindet. Damit will Red Hat die Komplexität aus der Verwaltung von Storage-Volumes nehmen, indem der Anwender die daruter liegenden Techniken nicht zwingend verstehen muss, um seinen Storage-Pool zu konfigurieren. Stratis setzt dabei auf XFS auf und soll diesem Dateisystem die Tricks von Btrfs und ZFS beibringen.

    Verschlüsselung

    In diesem Bereich bietet RHEL 8 zudem Unterstützung für LUKSv2 zur Verschlüsselung von lokalen Daten in Kombination mit Network-Bound Disk Encryption (NBDE) für mehr Datensicherheit und vereinfachten Zugriff auf verschlüsselte Daten. Snapshots des Dateisystems ermöglichen zudem eine schnellere Durchführung von Aufgaben auf Dateiebene, wie das Klonen virtueller Maschinen, während sie gleichzeitig Platz sparen, indem sie neuen Speicher nur dann verbrauchen, wenn sich Daten ändern.

    Container-Tools

    Im Bereich Cloud und Container erhielt RHEL 8 ein Werkzeugset bestehend aus Buildah zum Erstellen von Container-Images, Podman zur Verwaltung sowie Skopeo zur Handhabung dieser Images in Repositories. Wird statt Containern eine Virtuelle Mschine benötigt, ermöglicht RHEL mit Composer die Erstellung und das Ausrollen benutzerdefinierter Images in der Hybrid-Cloud mit einer einfachen grafischen Benutzeroberfläche.

    Gnome, kein Plasma

    Die RHEL 8 Beta basiert auf Kernel 4.18 und bietet Gnome 3.28, falls eine grafische Oberfläche gebraucht wird. KDEs Plasma-Desktop wird ab dieser Beta nicht mehr unterstützt. Ebenso entfällt die Unterstützung für Btrfs. Als weitere  Software sind unter anderem Apache 2.4, Nginx 1.14, MariaDB 10.3, MySQL 8.0, PostgreSQL 9.6 und 10, PHP 7.1 sowie Node.js 8 und 10 mit im Paket.

    Weitere Einzelheiten vermittelt die Ankündigung des Herstellers. Die Betaversion steht in 64-Bit für die Architekturen x86, ARM, Power und System Z den Red-Hat-Kunden sowie registrierten Entwicklern zum Test zur Verfügung.

  • Stratis – Red Hats neues Storage-System

    Stratis – Red Hats neues Storage-System

    Im August 2017 erklärte Red Hat seine vermutlich endgültige Abkehr vom Btrfs-Dateisystem. Bald darauf wurde klar, dass ein neu gestartetes Projekt zu Red Hats künftiger Speichertechnologie werden soll. Die Rede ist von Stratis, dass vor wenigen Tagen mit Fedora 28 erstmals vorgestellt wurde und für Fedora 29 eine erste stabile Version 1.0 anstrebt.  Stratis soll eine ähnliche Funktionalität wie ZFS und Btrfs bieten, allerdings basierend auf einem hybriden Modell. Da ZFS aus lizenzrechtlicher Sicht für Red Hat nicht infrage kommt und Btrfs eigene Probleme im Zusammenspiel mit Docker zeigt, entschied sich Red Hat zu dieser partiellen Neuentwicklung, die vor rund einem Jahr in einem White-Paper (PDF) vom Hauptentwickler Andy Grover erstmals beschrieben wurde.

    Nicht neu erfunden

    Dabei will Red Hat aber kein neues Dateisystem schreiben, sondern aus bestehenden Komponenten eine Lösung bauen, die dem Anwender eine gut integrierte Lösung mit konsistenter Konfiguration bietet. Hauptentwickler Andy Grover beschreibt es in dem Papier als eine Kommandozeilenlösung mit einer umfassenden API, die auf bestehenden Techniken aufbaut und in Rust und Python umgesetzt wird. Stratis soll dabei nicht nur den Geschäftskunden von Red Hat die Konfiguration und Pflege riesiger Disk-Arrays erleichtern, sondern auch dem Desktop-Anwender mit nur einer SSD.

    Vereinfachend

    Stratis zielt darauf ab, drei Dinge einfacher zu machen: die anfängliche Konfiguration des Speichers, spätere Änderungen und die Verwendung erweiterter Speicherfunktionen wie Snapshots, Thin Provisioning und sogar Tiering. Es bedient sich dabei des Konzepts des Storage-Pools, bei dem eine oder mehrere Disks zunächst unspezifiziert zusammengefasst werden, um später mehr Flexibilität zu bieten als dies feste Partitionen tun. Im Gegensatz zu LVM wird, ähnlich wie bei einem Virtual-Machine-File-System (VMF) das Dateisystem mit dem Pool verschmolzen, was bei Btrfs als Subvolume bekannt ist. Bei Stratis heißt es einfach Filesystem, dessen einzige Größenbeschränkung die Größe des Pools darstellt.

    Was unterscheidet Stratis von ZFS, Btrfs und LVM?

    Anstatt ganz von vorne zu beginnen versuchen die Entwickler bei Stratis von den Fehlern der Vorgänger zu lernen und bestehende Komponenten zu nutzen. Das Device-Mapper-Framework (DM), dessen sich auch LVM bedient um blockorientierten Geräten Funktionen wie RAID und Thin Provisioning  zur Verfügung zu stellen arbeitet hierfür zusammen mit dem XFS-Dateisystem. Von ZFS wurde der kommandozeilenbasierte Ansatz übernommen sowie die Art und Weise, wie Festplatten zu einem Pool hinzugefügt oder ersetzt werden.

    Bei Btrfs wurden Anleihen beim Konzept der Dateisystem-Snapshots und der Redundanz gemacht. Am weitesten reicht die Verwandtschaft jedoch bei LVM, da beide auf DM als grundlegende Komponente setzen. Stratis soll aber einfacher zu handhaben sein, ohne allzu viel von der breiten Funktionalität von LVM vermissen zu lassen. Somit wird Stratis eine weitere Möglichkeit bieten, einen Storage-Pool zu konfigurieren und zu verwalten.

    Zeitplan offen

    Mit Version 1.0 soll Stratis Snapshots beherrschen, für Stratis 2.0 ist die Integration von RAID und Write-Through-Caching geplant. Mit Version 3.0 soll die Funktionsparität mit ZFS erreicht sein. Abgesehen von Stratis 1.0, das mit Fedora 29 im Oktober erwartet wird, ist noch kein weiterer Zeitplan bekannt.