SSDs als Cache für Festplattenspeicher

© © Peter Lecko, 123RF

Hochgeschwindigkeit

Festplatten sind heute günstig, aber immer noch nicht besonders schnell, SSDs dagegen schnell aber teuer. Der Königsweg liegt derzeit darin, beides zu kombinieren und SSDs als schnelle Caches für Festplatten zu verwenden.
Security ist ein stets aktuelles Thema in der IT. Deshalb widmet sich das ADMIN-Magazin 04/2012 speziell Sicherheitsaspekten und gibt Antworten auf die Fragen: ... (mehr)

Solid State Drives (SSDs) sind aus modernen IT-Umgebungen nicht mehr wegzudenken. Für große Storage-Systeme, die sowohl mit Kapazität als auch Performance glänzen sollen, kann eine Ausstattung rein mit SSDs aber schnell sehr kostspielig werden. Abhilfe schaffen hier SSD-Caching-Technologien, die eine Art "Hybrid-Speicher" bereitstellen.

Traditionelle Festplatten (HDDs) werden dabei mit SSDs kombiniert und vereinen die Vorteile beider Welten. Die SSD fungiert als Cache für die Festplatten und beschleunigt mit ihrer größeren Performance Lese- und Schreibzugriffe. Dieser Geschwindigkeitsvorteil kommt vor allem dann zum Vorschein, wenn die typischerweise genutzten Datenmengen die Größe des Arbeitsspeichers (RAM) überschreiten, die Größe der SSD jedoch nicht. Im Regelfall wird ungenutzter Arbeitsspeicher als Page Cache für die Bufferung von Dateien verwendet. Das Linux Kommando »free -m« zeigt in der Spalte »cached« , wie viele MByte gerade als Cache dienen. Nicht immer aber reicht der Page Cache für ein Datenset aus, und in manchen Fällen übersteigt es sogar die maximal mögliche Größe des RAM eines Hosts.

Ist der Page Cache zu klein für ein Datenset, müssen normalerweise Teile davon auf der Festplatte bleiben. Der Performance-Unterschied zwischen RAM und HDD wird durch eine SSD-Zwischenschicht gemindert. Passt das Datenset auf die SSD, werden Lese- und Schreiboperationen komplett auf SSD-Ebene abgearbeitet. Nur zur Synchronisation der Daten muss auf die HDD zurückgegriffen werden.

Facebook-erprobt

Flashcache bietet eine einfache software-basierende Lösung für die Verwendung eines SSD-Caches. Es wird aktuell von Facebook entwickelt und aktiv in deren Serverumgebungen eingesetzt [1]. Bevor jedoch SSD-Caching für den eigenen Gebrauch zum Einsatz kommen kann, gibt es wichtige Fragen zu klären:

  • Welches Zugriffsmuster zeigen die verwendeten Applikationen? Greifen sie eher nur lesend auf die Daten zu oder besteht ein ausgewogenes Verhältnis zwischen Lesen und Schreiben?
  • Wie groß ist die Datenmenge, die die Applikationen benötigen? Reicht der vorhandene Arbeitsspeicher aus, um die Daten im Page Cache zu halten, oder sind sie häufig größer? Würde sich das vorhandene Datenset für einen SSD-Cache eignen?
  • Gibt es aktuelle Messungen, die Performance-Einbußen aufgrund des Einflusses der Speicher-Systeme belegen?

Aus diesen Fragen geht hervor, dass SSD-Caching und somit auch Flashcache kein Allheilmittel für eine Performance-Steigerung sind. Nur wer sein System und dessen Verhalten genau kennt, kann mit einem SSD-Cache Erfolge erzielen.

Flashcache eignet sich vor allem durch seine Einfachheit und die Verfügbarkeit als Open-Source-Software als Kandidat für eine erste Tuchfühlung mit Caching. Der Quellcode kann von Facebooks Github-Webseite heruntergeladen und unter Linux in ein Kernel-Modul übersetzt werden. Flashcache baut auf dem Linux Device Mapper auf, einer Komponente im Linux-I/O-Stack die unter anderem der Logical Volume Manager (LVM) nutzt [2]. Die Flexibilität dieser Architektur zeigt sich bei Flashcache zum Beispiel in der Tatsache, dass ein redundanter Cache aus mehreren SSDs erzeugt werden kann oder einzelne Partitionen der SSD für unterschiedliche HDDs zum Einsatz kommen können.

Caching-Modi

In Bezug auf die Cache-Art unterstützt Flashcache drei Varianten: Write-Back, Write-Through und Write-Around Caching (Abbildung 1) [3]. Der Write-Back-Modus bietet als einziger Modus die Möglichkeit zur Beschleunigung von Schreibzugriffen ("Writes"). Diese Writes schreibt das Modul im ersten Schritt auf die SSD und synchronisiert sie später im Hintergrund mit der HDD – dieser Vorgang wird auch als "Lazy Dirty Cleaning" bezeichnet. Diese "Dirty Pages" sind jene Blöcke, die sich im Cache auf der SSD befinden, aber noch nicht auf die HDD geschrieben wurden.

Abbildung 1: Die drei Cache-Arten, die Flashcache unterstützt.

In diesem Zusammenhang zeigt sich die Wichtigkeit eines redundanten Caches bei der Verwendung von Write-Back. Fällt eine SSD aufgrund eines Hardware-Fehlers aus, gehen die Dirty Pages unwiederbringlich verloren und können im schlimmsten Fall ein ganzes Dateisystem lahmlegen. Eine redundante Auslegung der Caching-SSDs, zum Beispiel durch einen RAID1-Verbund, kann dieses Desaster verhindern. Vorsicht: Wenn eine SSD des RAID-Verbunds ausfällt, läuft der Write-Back-Modus weiter, einen automatisierten Wechsel in den Write-Through-Modus gibt es bislang noch nicht. Im Fehlerfall ist daher aus Gründen der Datensicherheit ein rascher Tausch der defekten SSD nötig.

Wird ein Cache im Write-Through-Modus eingesetzt, schreibt das Modul synchron auf die SSD und die HDD. Der Geschwindigkeits-Vorteil der SSD kommt in diesem Fall also beim Schreiben nicht zur Geltung, da die Zugriffe erst dann abgeschlossen sind, wenn sie auch auf der langsameren HDD abgeschlossen sind. Der Vorteil des Cache macht sich erst bei darauffolgenden Lesezugriffen bemerkbar, bei denen die Daten von der SSD bereitgestellt werden können.

Im Write-Around-Modus wird die SSD als reiner Lese-Cache verwendet. Der Cache füllt sich erst nach und nach durch die Lesezugriffe.

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