Seite 2: Optimierungen für RAID, SSDs und TCP

Inhaltsverzeichnis

Schutz gegen Datenverfälschung bei RAID 5

Der Mdraid-Code kann Software-RAIDs der Level 4, 5 und 6 nun mit einem weiteren Datenträger koppeln, auf dem er ein Log führt, um RAID-Inkonsistenzen bei Systemabstürzen zu verhindern (u.a. 1, 2, 3). Das Schutzverfahren ähnelt dem von Journaling-Dateisystemen wie Ext4: Der Kernel schreibt jede Änderung zuerst in das Log, bevor es sie auf die am RAID beteiligten Datenträger schreibt. Fällt die Stromversorgung beim Schreiben auf die RAID-Datenträger aus, kann der Kernel beim nächsten Start die im Log hinterlegten Daten nutzen, um die Änderungen wie geplant durchzuführen. So kann der Kernel eine als "Write Hole" bekannte Gefahr vermeiden und die Integrität eines RAIDs innerhalb kurzer Zeit wieder herstellen, ohne das RAID von vorne bis hinten prüfen zu müssen, wie es bislang nach Abstürzen sinnvoll ist.

Das Log kann auch die Geschwindigkeit ein klein wenig steigern, da es Änderungen kurz puffert. Vorerst benötigt man noch eine Entwicklerversion des Tools Mdadm, um ein RAID mit Log-Datenträger einzurichten. Weitere Hintergründe erläutert ein Artikel des Mdadm-Entwicklers bei LWN.net. Die Log-Funktion für Mdraid stammt von Facebook-Mitarbeitern, die bereits an Erweiterungen arbeiten, die das Log zu einem vollwertigen Writeback-Cache machen. Dabei puffert das Log länger und mehr, um die Geschwindigkeit noch weiter zu steigern.

Bessere Interaktion mit High-End-SSDs

Neu ist auch Kernel-seitige Unterstützung für ein LightNVM genanntes Framework, das für "Open-Channel SSDs" gedacht ist (u. a. 1, 2, 3 4). Mit diesem Begriff bezeichnen die LightNVM-Entwickler einige vornehmlich für Server gedachte SSDs, bei denen das Betriebssystem Arbeiten übernehmen kann, die normalerweise der Flash Translation Layer (FTL) oder das Bad Block Management der SSD-Firmware erledigen. Das soll die Geschwindigkeit steigern, denn das Delegieren ans Betriebssystem vermeidet nicht nur Overhead, sondern auch störende Wechselwirkungen zwischen SSD-Firmware und Betriebssystem. Derzeit gibt es aber nur eine Handvoll SSDs, die das beherrschen. Weitere Hintergründe liefert ein LWN.net-Artikel und die Homepage des LightNVM-Projekts.

High-End-SSDs ausreizen

Geschwindigkeitssteigerungen bei High-End-SSDs für Server verspricht auch eine neue, noch experimentelle Infrastruktur für den Block-Layer. Bei ihr nutzt der Kernel Polling, wenn er große Datenmengen mit besonders schnellen Datenträgern austauscht (u.a. 1, 2, 3, 4). Das soll Latenzen senken und den Durchsatz steigern: Bei der Verarbeitung riesiger Datenmengen macht ein regelmäßiges Abrufen neuer Daten beim Controller weniger Arbeit als die Abarbeitung einer Vielzahl von Interrupts, die sonst entstehen. Dieser bei LWN.net näher erläuterte Ansatz ist nicht neu, denn das Netzwerksubsystem und viele Netzwerk-Treiber beherrschen diesen Trick schon länger.

TCP-Verbindungsaufbau optimiert

Linux 4.4 kann TCP-Handshakes schneller verarbeiten. Das reduziert Latenzen und erschwert zugleich DDoS-Attacken, schließlich kann der Kernel nun mehr Anfragen abarbeiten, bevor die Last so groß wird, dass er ins Straucheln gerät. Die bessere Performance ist unter anderem einigen Optimierungen der Locking-Mechanismen im TCP-Code zu verdanken (u. a. 1). Bei Tests durch den zuständigen Entwickler steigerten diese Änderungen die Zahl der per SYN/ACK hergestellten TCP-Verbindungen um das Zwei- bis Dreifache. Der Entwickler hat darüber hinaus noch einige Umbauten an Codepfaden für das SO_REUSEPORT-Flag vorgenommen (u. a. 1), über das mehrere Anwendungen auf einem Port lauschen können; das konnte die Zahl der TCP-Handshakes noch mal nahezu verdoppeln.

[Update, 14.01.16, 09:15] Auf Nachfrage stellte der zuständige Entwickler klar, dass er keine zwei- bis dreifache Steigerung gemeint hat, wie sie der Kernel-Log-Autor fälschlicherweise unterstellt hatte; gemeint gewesen sei vielmehr eine Steigerung um mehrere Größenordnungen. Die bezog sich aber nicht auf den Zustand direkt vor den Änderungen, sondern auf den Stand von zwei Jahren zuvor. Damals hat der Entwickler auf seinem Testsystem nur ungefähr zwanzigtausend TCP-Verbindungen per SYN/ACK hergestellten können. Zusammen mit den SO_REUSEPORT-Änderungen sollen es laut dem Entwickler nun rund sechs Millionen sein – also rund dreihundert Mal mehr als damals. [/Update]

Paketverluste besser erkennen

Der neue Package-Loss-Algorithmus RACK (Recently ACK) verspricht die Geschwindigkeit von TCP-Verbindungen zu steigern, bei denen häufiger Netzwerkpakete verloren gehen. Dazu versucht RACK etwaige Paketverluste anhand der Übertragungszeiten anderer Pakete zu erkennen, und nicht anhand der Reihenfolge, in der sie eintreffen, wie es bisherige Algorithmen meist tun. RACK ist vorerst experimentell und stammt von Google. Das Unternehmen setzt den Algorithmus offenbar schon eine Weile ein und hat ihn bei der IETF zur Standardisierung eingereicht.