Seite 4: Datenintegritäts-Schutz für RAID 5

Inhaltsverzeichnis

Mit dem "Partial Parity Log for MD RAID 5" (RAID5-PPL) bringt der Kernel jetzt eine zweite Technik, um die Integrität eines RAID-5-Verbunds auch bei Abstürzen hundertprozentig zu gewährleisten (u. a. 1, 2, 3, 4, Dokumentation). Solche können durch das sogenannte "Write Hole" zu Datenschäden führen, falls der Kernel neue Daten schreibt, diese aber durch den Absturz nicht komplett auf den am Verbund beteiligten Datenträgern landen. Die Paritätsdaten passen dann nicht zu den bereits geschriebenen Daten; falls nach dem Absturz ein Datenträger des RAID fehlen sollte, verfälscht der Rebuild in dem Bereich die Daten.

Die RAID5-PPL schützt dagegen, indem es beim Schreiben einige zusätzliche Informationen speichert, mit denen es den beschriebenen Fall abfangen kann. Das macht Arbeit, daher geht das Ganze zu Lasten der Geschwindigkeit. Laut dem federführenden Entwickler sinkt die Performance um bis zu 30 bis 40 Prozent. Diesen Nachteil nehmen einige Nutzer dennoch in Kauf, um die Daten in Sicherheit zu wiegen.

Alternativ kann man das mit dem Log-Device erreichen, mit dem man sich seit Linux 4.4 vor dem Write Hole schützen kann. Dessen Nachteil: Man muss das RAID mit einem weiteren Datenträger koppeln, auf dem der RAID-Code ein Journal führt. Seit Linux 4.10 kann dieses Log-Device aber zugleich auch als Write-Back-Cache nutzen und so die Performance des Verbunds sogar steigern.

RAID5-PPL stammt von Intel-Entwicklern und ging aus einer Funktion hervor, die die Windows-Treiber für Intels Rapid Storage Technology (RST) bei der neuen Xeon-Platform bieten soll. Bei RST funktioniert sie nur dort; die in Linux eingeflossene Implementierung ist kompatibel zu jener von Intel, arbeitet aber auf beliebiger Hardware.

Authenticated Encryption im Device Mapper

Das neue Device-Mapper-Target "dm-integrity" stellt ein Block Device bereit, das zu jedem gespeicherten Sektor einige Metadaten für spätere Integritätsprüfungen speichert. Das Device-Mapper-Target sorgt dabei für Atomic Updates, damit Nutz- und Metadaten garantiert zusammenpassen, selbst wenn eine Schreiboperation durch einen Absturz unterbrochen wird (1, 2). Zusammen mit der ebenfalls neuen Cryptographic Data Integrity Protection gelingt so Authenticated Encryption (AE). Durch diese kann der Kernel erkennen und warnen, wenn Blöcke eines verschlüsselten Volumes ohne den passenden Schlüssel modifiziert wurden (u. a. 1, 2, 3).

Ferner gab es einige Optimierungen am Device Mapper, auf den Cryptsetup oder der Logical Volume Manager (LVM) zurückgreifen (1, 2). Eine der Umbauten verspricht Latenzen beim Dm-Cache-Target zu reduzieren, mit dem sich ein SSD-Cache vor Festplatten oder Netzwerklaufwerke schalten lässt. Über die auf den MD-Code zurückgreifende RAID-Implementation des Device Mappers lässt sich nun auch die Cache-Funktion eines Log-Device aktivieren.

Verbrauch von I/O-Ressourcen flexibler regeln

Mit den Änderungen am via Mdadm administrierten MD-Subsystem stießen einige Patches zum Kernel, die die Performance von Festplatten-Verbünden der RAID-Level 5 oder 6 steigern sollen (u. a. 1, 2). Einige andere Anpassungen versprechen zudem, ein RAID-5-Recovery zu beschleunigen (u. a. 1).

Über das "Pblk" Target kann man nun über ein normales Blockdevice auf Open-Channel SSD zugreifen. Anders als normale SSDs haben diese eher exotischen SSDs kein Flash Translation Layer (FTL), daher muss der Kernel die davon erledigten Aufgaben wie das Wear Leveling selbst behandeln. Diese Aufgabe hat das LightNVM-Framework, das bei Linux 4.4 zum Kernel stieß.

Unter den Änderungen am Block Layer (1, 2, 3) waren noch eine Reihe weitere Features, darunter einige am Blk-Throttle. Mit diesem Control Groups (Cgroup) Controller lässt sich regeln, wie viele I/O-Ressourcen die Prozesse eines Systems nutzen dürfen. Durch die Änderungen gibt es eine Reihe neuer Einstellmöglichkeiten, die eine skalierbare Priorisierung ermöglichen, damit die Wete besser zu den gerade herrschenden Umgebungsbedingungen passen (u. a. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10).