Speicher muss nicht nur laufend größer werden, sondern auch schneller. In Zeiten von Virtualisierung und immer leistungsfähigeren Rechnern, die zeitnah auf ... (mehr)

dm-cache – Linux bringts mit

dm-cache ist seit Linux 3.9 offizieller Teil des Kernels. Ein per dm-cache beschleunigtes System besteht aus drei Devices, die zusammen ein Speichermedium realisieren. Neben einem Daten- und einem Speicher-Device ist zudem ein Gerät notwendig, das für die Speicherung der Metadaten verantwortlich zeichnet. dm-cache nutzt es zum Ablegen von Informationen über die Zugriffshäufigkeit: Caches funktionieren prinzipbedingt immer dann besonders zuverlässig, wenn sie umfassendes Wissen über die anfallende EA-Last besitzen.

Cache und Metadaten liegen so gut wie immer auf zwei Partitionen der SSD, während der eigentliche Massenspeicher auf magnetischen Festplatten ruht. Für die Berechnung des Cache empfehlen die Entwickler die Formel 4 MByte + (16 Bytes + nr_blocks) – weitere Informationen zu ihrer Ableitung finden sich unter [2].

Die Erstellung eines neuen dm-cache-Volume muss bei jedem Systemstart von Hand erfolgen: »dmsetup create device_name --table« nimmt eine vergleichsweise komplexe Parameterliste entgegen, die in der Dokumentation näher beschrieben ist. Beachten Sie, dass das System die unter »/dev/mapper/name« erstellten Volumes von Haus aus nicht mountet: Vor ihrer Nutzung ist manuelles Mounting erforderlich, um sie ins Dateisystem einzuhängen.

Während der Nutzung des gecachten Volume können Sie Informationen über den Systemzustand einholen. Dazu müssen Sie das Kommando »dmsetup status /dev/ mapper/dmcache_name« eingeben – die zurückgegebenen Indikatoren sind unter [3] genauer beschrieben.

FlashCache – Caching à la Facebook

Wer große Datenmengen verwaltet, denkt naturgemäß immer über Methoden zur Steigerung der I/O-Performance nach. Facebook setzt auf FlashCache, das bei STEC Electronic zu EnhanceIO ausgebaut wurde. Das Produkt sitzt auf dem Linux Device Mapper und arbeitet somit nicht auf Dateisystem-, sondern auf Blockebene. Eingehende I/O-Abfragen durchlaufen eine Analyse, häufig verwendete Blöcke wandern in den Cache. Für Schreiboperationen kennt das System drei verschiedene Betriebsmodi: Write-Around, Write-Back und Write-Through.

Der Parameter "skip_seq_thresh_kb" erlaubt das Festlegen eines Grenzwerts, ab dem der Cache Leseoperationen nicht mehr berücksichtigt. Es handelt sich dabei um eine Performance-steigernde Maßnahme, die die im folgenden Abschnitt beschriebene Problematik entschärfen soll.

Das Fehlen eines dedizierten Metadatenspeichers lässt den Cache auf manche Arten von EA-Last empfindlich reagieren. FlashCache orientiert sich bei der Auswahl der zu cachenden Blöcke an der letzten Verwendung – historische Informationen über die vergangene Zugriffshäufigkeit berücksichtigt das Produkt nicht. Es erfolgt also keine Hot-Spot-Detection. Antiviren-Scans, Suchprozesse und ähnliche sequenzielle Lesevorgänge sorgen in dieser Situation dafür, dass der Cache diverse, nur wenig nützliche Inhalte aufliest. Nach dem Ablauf der Suche müssen die eigentlich benötigten Dateien abermals eingesammelt sein, bevor sie wieder mit Performance-Steigerungen rechnen dürfen.

Ä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