OVH NEWS | Aktuelles, Innovationen und IT Trends








12. Januar 2016
Teilen

Geschrieben von OVH Team


Neun Ideen, die OpenZFS noch besser machen


2. Teil unseres OpenZFS Dossiers


„Die Präsentationen der verschiedenen Teilnehmer waren durchweg auf einem sehr hohen technischen Niveau“, berichten François Lesage und Alexandre Lecuyer. Und sie alle können als Versprechen für eine wunderbare Zukunft von OpenZFS betrachtet werden. Davon werden die Nutzer kurz-, mittel- und langfristig profitieren.“

Die neun Beiträge, die OpenZFS noch leistungsfähiger machen werden:

1 – Compressed ARC (Adaptive Replacement Cache)
OpenZFS verwendet ein System mit zwei Cache-Ebenen (ARC und L2ARC), worin die am häufigsten abgerufenen Daten gespeichert werden. Der L1-Cache verwendet RAM-Ressourcen, der L2-Cache dagegen die Festplatten – meist SSD. Der Beitrag von George Wilson (Delphix) zielt darauf ab, die Komprimierung/Dekomprimierung von Dateien im L1-Cache/RAM während der Übertragung zu ermöglichen. So würde beispielsweise eine .txt-Datei im Cache nur noch ein Drittel an Speicherplatz benötigen (allerdings ist bei bereits komprimierten Dateitypen keine weitere Komprimierung möglich, etwa bei .jpg). Das Ergebnis: Die Leistung des Cache kann bei gleichbleibenden Kosten deutlich verbessert werden. Verfügbarkeit in OpenZFS: kurzfristig.
Der Vortrag im Video

2 – Discontiguous caching with ABD
Das OpenZFS eigene Cache-System ARC ist redundant mit dem Cache des Betriebssystems, etwa Page Cache unter Linux. Das bedeutet, dass Dateien tatsächlich zweifach im Cache gespeichert werden: einmal im Cache von OpenZFS und ein zweites Mal im Cache des Betriebssystems. Dadurch geht RAM-Speicherplatz verloren. Der Beitrag von David Chen (OSNexus) zielt darauf ab, OpenZFS die Nutzung der standardmäßigen Caching-Mechanismen des jeweiligen Betriebssystems zu ermöglichen. Verfügbarkeit in OpenZFS: mittelfristig.
Der Vortrag im Video

3 – Persistent L2ARC
Der Caching-Mechanismus auf der zweiten Ebene ist bei OpenZFS besonders ausgeklügelt. Die Auswahl der im Cache gespeicherten Daten (in den meisten Fällen auf SSDs, die Produktion ist auf langsameren Platten gehostet) beruht auf zwei konkurrierenden Algorithmen, die in Echtzeit und auf Basis der durchgeführten Abfragen gemeinsam die beste Strategie zur Datenspeicherung bestimmen. Dieser Caching-Mechanismus hat aber eine Schwäche: Bei einem Neustart muss der Cache wieder neu aufgebaut werden. So kann es mehrere Stunden dauern (bis zu 24 Stunden etwa bei einem Shared-Hosting Filer Cache von OVH), bis wieder die maximale Leistung erreicht wird. Der Beitrag von Saso Kiselkov (Nexenta) ermöglicht es dank einer Formatänderung, sogar nach einem Neustart mit dem heißen Cache weiterzuarbeiten. Verfügbarkeit in OpenZFS: kurzfristig auf Illumos.
Der Vortrag im Video

4 – Writeback cache
Die Idee des Beitrags von Alex Aizman (Nexenta) besteht darin, einen Mechanismus für einen Schreibpuffer zu entwickeln, getrennt von den Festplatten, wo Log-Dateien gespeichert werden. So können beispielsweise bei Input-Bursts die Daten auf eine SSD oder eine PCI-Karte geschrieben und dann asynchron auf die Festplatten übertragen werden. Verfügbarkeit in OpenZFS: nicht bekannt.
Der Vortrag im Video

5 – Compressed Send and Receive
Der Beitrag von Dan Kimmel (Delphix) besteht darin, bei einem Backup oder einer Migration direkt einen komprimierten Datenstrom zu verschicken. Das ermöglicht den Verzicht auf die beiden Schritte der Dekomprimierung beim Verschicken und der „Rekomprimierung“ beim Empfangen. Als Ergebnis wird weniger Bandbreite benötigt, die Backup-Geschwindigkeit erhöht und die CPU-Belastung beim Backup reduziert. Verfügbarkeit in OpenZFS: kurz- bis mittelfristig.
Der Vortrag im Video

6 – Resumable ZFS send/receive
Dieser Beitrag von Matthew Ahrens (Delphix) wurde bereits vor sechs Monaten bei der OpenZFS European Conference in Paris vorgestellt. Mithilfe eines Tokens kann ein Backup wiederaufgenommen werden, wenn die Verbindung während der Datenübertragung unterbrochen wurde. Bisher wird nach einer Unterbrechung das Backup wieder komplett neu gestartet. Schon jetzt für Illumos und FreeBSD verfügbar, bald auch für Linux.
Der Vortrag im Video

7 – Parity Declustered RAID-Z/Mirror

Dieser Beitrag von Isaac Huang (Intel) basiert auf der Forschung der angewandten Mathematik und zielt darauf ab, den RAIDZ (OpenZFS RAID) im Falle eines Festplattenverlusts schneller wiederaufzubauen. Da Festplatten immer größer werden, kann das Resilvering eines RAIDZ mehrere Tage dauern. Und es kann passieren, dass eine zweite Festplatte des RAIDZ ausfällt, bevor die Wiederherstellung abgeschlossen ist. Dann ist die Gefahr eines permanenten Datenverlusts groß. Indem die Verteilung der Datenblöcke auf der Festplatte optimiert wird, wird dieses Projekt – das sich aber noch in Entwicklung befindet – die für die Wiederherstellung eines RAID benötigte Zeit deutlich reduzieren.
Der Vortrag im Video

8 – Dedup Ceiling
Datendeduplizierung gibt es bei OpenZFS schon lange. Tatsache ist aber, dass sie nur selten genutzt wird, weil sie gewisse Risiken birgt, wenn man mit vielen Dateien arbeitet. Die Dedup-Tabelle wird im RAM gespeichert, und wenn sie zu groß wird, nimmt die Antwortzeit des Deduplizierungssystems dramatisch zu. Der Beitrag von Saso Kiselkov (Nexenta) verfolgt das Ziel, die Dedup-Tabelle auf einem dedizierten Datenträger zu speichern, wobei ein Größenlimit festgelegt werden kann. Als Ergebnis könnte die Deduplizierung endlich verwendet werden. Die Vorteile für OVH im Bereich Shared Hosting könnten beträchtlich sein. So werden etwa die Core-Dateien von WordPress millionenfach repliziert. Die Deduplizierung würde hier enorm viel Speicherplatz freimachen. Verfügbarkeit in OpenZFS: mittelfristig.
Der Vortrag im Video

9 – SPA Metadata Allocation Classes
Der Beitrag von Don Brady (Intel) ist eine gute Gelegenheit, sich daran zu erinnern, dass das Herz von OpenZFS ein Objektspeicher ist, der als Dateisystem genutzt werden kann, indem unter Rückgriff auf die Objekt-Metadaten eine Baumstruktur erstellt wird. Einige gespeicherte Objekte sind also Dateien, andere Metadaten (UNIX, ACL, …). Und diese Objekte werden im ZFS-Pool wahllos gemischt. Die Arbeit von Don Brady zielt darauf ab, die Organisation der Objekte nach ihrer Art zu ermöglichen. So könnten beispielsweise Metadaten-Objekte SSD-Festplatten zugewiesen werden, um die Leistung des Pools zu verbessern. Außerdem ist die Möglichkeit vorgesehen, bestimmte Bauteile (SATA-Festplatten, SSDs, MVNE, …) spezifischen Typen von Metadaten zuzuordnen. Verfügbarkeit in OpenZFS: nicht bekannt.
Der Vortrag im Video
Lesen Sie im ersten Teil unseres OpenZFS Dossiers: Darum setzt OVH auf OpenZFS
Lesen Sie im letzten Teil unseres OpenZFS Dossiers: Zoom auf das OpenZFS Cache-System ARC