Systeme: So funktioniert der Linux Storage Stack

Sauber gestapelt

,
Abstraktionsschichten sind das A und O beim Design von komplexen Architekturen. Der Linux Storage Stack ist ein hervorragendes Beispiel für gut aufeinander abgestimmte Schichten. Zugriffe auf Speichermedien werden durch eine einheitliche Schnittstelle abstrahiert, ohne Funktionalität einzubüßen.
Speicher muss nicht nur laufend größer werden, sondern auch schneller. In Zeiten von Virtualisierung und immer leistungsfähigeren Rechnern, die zeitnah auf ... (mehr)

Endbenutzer sind im Kontext eines Storage-Stack in der Regel normale Anwendungen (Userspace Programme/Applikationen). Die erste Komponente, mit der Linux-Programme interagieren, wenn sie Daten verarbeiten, ist das Virtual Filesystem (VFS). Erst durch das VFS ist es möglich, dieselben Systemaufrufe (System Calls) für unterschiedliche Dateisysteme auf verschiedenen Medien aufzurufen. Mit ihm wird zum Beispiel für den Benutzer transparent eine Datei mit dem cp-Befehl von einem Ext4- auf ein Ext3-Dateisystem kopiert.

Die Vielfalt an Dateisystemen zeigt, dass die VFS-Kapselung unzählige Möglichkeiten eröffnet. Immerhin gibt es blockbasierte, netzwerkübergreifende oder Pseudo-Dateisysteme und sogar Filesysteme im Userspace (FUSE). Die erwähnten Systemaufrufe sind vereinheitlichte Funktionen wie open, read oder write, ganz gleich welches Dateisystem sich darunter verbirgt. Die spezifischen FS-Operationen werden vom VFS abstrahiert, zusätzlich gibt es Caches, die den Datei-Zugriff beschleunigen (unter anderem den Dentry Cache).

Die nächste Schicht des Storage Stack besteht aus den individuellen FS-Implementierungen. Sie bieten dem VFS generische Methoden an und übersetzen sie in spezifische Aufrufe für den Gerätezugriff. Zusätzlich implementiert das FS seine eigentliche Aufgabe – die Organisation von Daten und Metadaten für ein darunter liegendes Speichermedium. Der Linux-Kernel beschleunigt obendrein den Zugriff auf diese Medien mit einem Caching-Mechanismus – dem Linux Page Cache.

Block-I/O

Im Kernel werden zur Verwaltung keine Pages, sondern flexiblere Block-I/O-Strukturen (BIOs) eingesetzt. Die Strukturen repräsentieren Block-I/O-Operationen beziehungsweise Anfragen, die der Kernel aktuell abarbeitet (in flight BIOs). Das gilt sowohl für I/O über den Page Cache als auch für direct I/O, also Zugriffe, die den Page Cache umgehen. BIOs spielen ihren Vorteil bei der Handhabung mehrerer Segmente aus, die in die aktuelle I/O-Operation involviert sind.

BIOs bestehen aus einer Liste beziehungsweise einem Vektor von Segmenten, die auf unterschiedliche Pages im Speicher zeigen. Dadurch ergibt sich über ein BIO eine dynamische Zuordnung von Pages zu den tatsächlichen Sektoren auf dem Block-Device. Auf Seiten des Block-Layers trifft man ein weiteres Mal auf die BIO-Strukturen. Bevor der Kernel I/O-Operationen an die Dispatch Queue des Treibers übergibt, werden BIOs zu Requests zusammengefasst.

Stacked Block Devices

Eine wichtige Komponente des Linux Storage Stack ist direkt vor dem Block Layer angesiedelt. Hier sind logische Block Devices implementiert, die darunter zwar mit herkömmlichen Devices operieren, aber zusätzliche Funktionen umsetzen. Außerdem ist es möglich, die logischen Devices übereinanderzuschichten (sogenannte stacked Devices). Der Logical Volume Manager (LVM) oder Software RAID (mdraid) sind wohl die bekanntesten Vertreter, die beispielsweise die Skalierung logischer Volumes über die Grenzen physischer Datenträger hinaus erlauben oder Daten redundant speichern. Stacking wird häufig in der Kombination Festplatten, RAID und LVM umgesetzt. Wie Sie sehen, werden bereits einige Schritte durchlaufen, bevor wir tatsächlich im Block Layer ankommen.

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