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)

Strategien

Die beiden Tuning-Parameter »fallow_delay« und »dirty_thresh_pct« sind nur für den Write-Back-Modus von Bedeutung. Wie bereits erwähnt, werden Dirty Pages im Hintergrund von der SSD auf die HDD synchronisiert. Die Auswahl der Blöcke erfolgt entweder aufgrund eines Timeouts (»fallow_delay« ) oder beim Überschreiten eines Schwellwerts (»dirty_thresh_pct« ). Das Timeout kommt dann zum Zug, wenn ein Dirty Block im Cache für längere Zeit weder gelesen noch geschrieben wurde. Nach Überschreitung dieser Zeit im Idle-Zustand werden die Block-Daten auf die HDD geschrieben, und der Block verliert somit seinen Dirty-Zustand ("Idle Cleaning").

Der zweite Parameter bestimmt den Prozentanteil an Dirty-Blöcken eines Cache-Sets. Flashcache beginnt vermehrt Cache-Blöcke von der SSD auf die HDD zu schreiben, sobald die Anzahl an Dirty Blöcken den Prozentwert überschreitet. Die Auswahl der Blöcke erfolgt aufgrund der Reclaim Policy. Sie bestimmt die Blöcke, die Flashcache auswählt, wenn bei einem Write keine Blöcke mehr frei sind und wenn eine Clean-Operation ansteht. Zur Auswahl stehen "First in First out" (FIFO, per Default – der als Erstes hereinkam, fällt zuerst raus) und "Least recently used" (LRU, der am längsten nicht verwendete).

Über den Sysctl »reclaim_policy« kann zur Laufzeit eine der beiden Varianten ausgewählt werden. Wurde eine Auswahl an Blöcken getroffen, gibt es obendrein Möglichkeiten zur Steuerung der Anzahl an Clean Writes: »fallow_clean_speed« , »max_clean_ios_set« und »max_clean_ios_total« bestimmen, wie viele Writes beim Synchronisieren abgesetzt werden.

Black- und Whitelists

Über Black- und Whitelists lässt sich festlegen, welche Applikationen sich Flashcache zunutze machen. Das Caching einer Datenbank kann zum Beispiel wie folgt erreicht werden: mit dem Sysctl »cache_all« den Cache global deaktivieren. Den Thread Group Identifier des Datenbank-Daemons (zum Beispiel »mysqld« ) zur Flashcache-Whitelist hinfügen. Von nun an werden alle I/Os des Daemons gecacht, andere Applikationen nutzen den Cache nicht.

Dies funktioniert jedoch nur für Direct I/O zuverlässig, also Zugriffe, die nicht den Page Cache benutzen. Ansonsten werden Writes auch von den Kernel-Flush-Threads durchgeführt, die sich nicht auf der Whitelist befinden.

Blacklists sind unter anderem für Backup-Prozesse interessant, die von Zeit zu Zeit das Filesystem nach Änderungen durchforsten. Diese Read-Operationen sind ungeeignet für den SSD-Cache. Der Prozess ist ein Kandidat für die Blacklist und wird als »non-cacheable« gekennzeichnet.

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