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

Block-Layer

Der Block-Layer verarbeitet die zuvor geschilderten BIO-Strukturen. Er ist dafür zuständig, I/O-Anfragen von Anwendungen an die Speichergeräte weiterzuleiten. Er bietet dabei den Anwendungen einheitliche Schnittstellen für den Datenzugriff, egal ob es sich um eine Festplatte, eine SSD, ein FC-SAN-Storage oder um ein anderes blockbasiertes Speichergerät handelt. Zusätzlich bietet der Block-Layer für Speichergeräte und deren Treiber einen einheitlichen Zugangspunkt für alle Anwendungen. Er verbirgt auf diese Art und Weise die Komplexität und Diversität der Speichergeräte vor den Anwendungen.

Zusätzlich sorgt der Block-Layer für eine gerechte Verteilung von I/O-Zugriffen, eine entsprechende Fehlerbehandlung, Statistiken und eine Ablaufplanung. Letztere soll vor allem die Performance verbessern und Anwender vor Performancenachteilen durch schlecht implementierte Anwendungen oder Treiber schützen.

Abhängig vom jeweiligen Gerätetreiber und der Konfiguration gibt es im, beziehungsweise um den Block Layer herum, drei Pfade für Daten:

1. Den Weg über einen der drei traditionellen I/O-Scheduler NOOP, Deadline oder CFQ. Der vormals vierte traditionelle I/O Scheduler AS (anticipatory) wies viele Ähnlichkeiten mit CFQ auf und wurde daher von Jens Axboe, dem Maintainer des Linux Block-Layers, mit Kernel Version 2.6.33 entfernt.

2. Den Weg über den mit Linux Kernel 3.13 eingeführten und damit noch relativ neuen Linux Multi-Queue Block I/O Queueing Mechanism (blk-mq). Die Linux Kernel-Entwickler haben blk-mq vor allem für hochperformante Flashspeicher wie PCIe-SSDs entwickelt, um die IOPS-Performance-Limitierungen der traditionellen I/O-Scheduler zu durchbrechen.

3. Eine Umleitung um den eigentlichen Block-Layer herum direkt zu BIO-basierten Treibern. Hersteller von PCIe-SSDs haben in der Zeit vor blk-mq solche aufwendigen Treiber entwickelt, die viele Aufgaben des Block-Layers selbst implementieren müssen.

I/O-Scheduler

Die traditionellen I/O-Scheduler NOOP, Deadline und CFQ haben bei den aktuellen Linux-Distributionen für den Unternehmenseinsatz sicherlich noch die größte Bedeutung. Selbst die neuesten Distributionen wie Debian 8 kommen nicht über Kernel Version 3.16 hinaus – und diese Kernel-Version unterstützt für blk-mq neben einem Testtreiber (null_blk) nur einen virtuellen Treiber (virtio-blk, zum Beispiel für KVM-Gäste) und einen "echten" Treiber (mtip32xx für die Micron RealSSD PCIe).

Ein näherer Blick auf die Funktionsweise der traditionellen I/O-Scheduler lohnt sich daher weiterhin. Sie arbeiten mit den folgenden zwei Warteschlangen (Queues):

- Request Queue: In dieser werden die von Prozessen abgesetzten Anfragen gesammelt, optional zusammengefasst (merge) und vom Scheduler je nach Scheduling-Algorithmus sortiert. Die Scheduler verwenden unterschiedliche Ansätze, um die einzelnen Anfragen zu behandeln und an den Gerätetreiber zu übergeben.

- Dispatch Queue: Beinhaltet geordnete Anfragen, die bereit für die Abarbeitung am Speichergerät sind. Sie wird vom Gerätetreiber verwaltet.

Der NOOP-Scheduler ist ein einfacher Scheduler, der alle I/O Anfragen in einer FIFO-Queue sammelt. Er führt zur Optimierung der Anfragen ein Merging durch und reduziert damit unnötige Zugriffszeiten. Er sortiert die Anfragen jedoch nicht. Der Gerätetreiber arbeitet die Dispatch Queue ebenfalls nach dem FIFO-Prinzip ab. Der NOOP-Scheduler verfügt übrigens über keine Einstellungsmöglichkeiten zur Optimierung (Tunables).

Der Deadline-Scheduler (Bild 1) versucht das sogenannte "Verhungern" (Starvation) von Anfragen zu verhindern. Dazu vermerkt er bei jedem Request eine Ablaufzeit (Expiration

Time) und schiebt ihn in zwei verschiedene Warteschlangen: in eine "Sorted Queue" und in eine "Deadline Queue". Im schlechtesten Falle sollen Requests nach einer definierten Verfallsdauer (Expiration Time) abgearbeitet werden. Es wird also versucht, eine vorhersagbare Service-Start-Zeit zu garantieren.

Bild 1: Der Deadline-Scheduler versucht mit zwei Warteschlangenpaaren das "Verhungern" von Anfragen zu verhindern.

Lesezugriffe behandelt der Deadline-Scheduler gegenüber Schreibzugriffen bevorzugt, sie besitzen daher auch eine kürzere Deadline (standardmäßig 0,5s im Vergleich zu 5s von Schreibzugriffen). Diese Maßnahme ist insofern von Vorteil, da Lesezugriffe zumeist synchron (blockierend) und Schreibzugriffe asynchron (nicht-blockierend) abgesetzt werden. Für die Verwaltung aller Abfragen verwendet der Deadline-Scheduler insgesamt zwei Warteschlangenpaare für Lese- und Schreibzugriffe:

- Eine nach Sektoren sortierte Warteschlange

- Eine First-In-First-Out-Warteschlange mit der Reihenfolge aufgrund der Deadline (Deadline Queue)

Bild 2: Der CFQ-Scheduler arbeitet mit Prioritäts- beziehungsweise Scheduling-Klassen.

Der CFQ (Completely Fair Queuing) Scheduler (Bild 2) ist der Standard-Scheduler des Linux-Kernels, wobei manche Distributionen stattdessen den Deadline-Scheduler einsetzen. CFQ setzt sich die folgenden Ziele:

- Eine faire Aufteilung der vorhandenen I/O-Bandbreite auf alle Prozesse gleicher Prioritätsklassen via Time-Slices. Diese "Fairness" bezieht sich auf die Länge der Time-Slots und nicht auf die Bandbreite, das heißt ein Prozess mit sequenziellen Schreibzugriffen wird im gleichen Time-Slot eine höhere Bandbreite erzielen als ein Prozess mit zufällig verteilten Schreibzugriffen.

- Die Möglichkeit, Prozesse in Prioritäts- beziehungsweise Scheduling-Klassen einzuteilen (zum Beispiel via ionice).

- Periodische Abarbeitung der Prozess-Queues zur Verteilung der Latenz. Die Time-Slots ermöglichen für Prozesse, die viele Requests in ihrem Slot absetzen können, eine hohe Bandbreite.

comments powered by Disqus
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

Ausgabe /2023