DVR-Archivspeicher und SSD-Cache¶

Anhang für Installationen mit großem Archiv: wie der Knoten das DVR-Archiv liest, wie sich die Last auf die Festplatten abschätzen und zwischen HDD und SSD wählen lässt, wie ein SSD-Cache vor einem HDD-Array mit Mitteln des Betriebssystems eingerichtet wird und wie das System abgestimmt wird. Die Konfiguration der Speicher selbst und der Bereinigung ist in DVR-Speicher beschrieben, ihre Überwachung in DVR-Monitor.

Alle Zahlen auf dieser Seite sind Richtwerte und Beispiele für eine Abschätzung, kein Leistungsversprechen: Die tatsächliche Last hängt vom Publikum, vom Satz der Kanäle und von der Hardware ab.

1. Wie der Knoten das Archiv liest¶

Der Knoten schreibt das Archiv in gewöhnliche Dateien im Verzeichnis des Speichers und liest sie mit gewöhnlichem Dateilesen. Daher läuft jedes Lesen des Archivs über den Seitencache von Linux: Wiederholtes Lesen derselben Segmente wird aus dem Arbeitsspeicher bedient, ohne Zugriff auf die Festplatte. Der Arbeitsspeicher ist die erste und kostenlose Cache-Ebene; dafür muss am Knoten nichts konfiguriert werden.

Fast ohne Festplattenzugriffe werden aus dem Speicher bedient:

Timeshift und Wiedergabe ab Sendungsbeginn innerhalb von etwa einer halben bis einer Stunde ab dem Live-Signal: Diese Segmente sind gerade erst geschrieben worden und liegen noch im Cache;
beliebte Sendungen und Ereignisse, die hunderte Zuschauer gleichzeitig ansehen: Die Festplatte liest ein solches Segment einmal, die übrigen Zuschauer erhalten es aus dem Speicher;
frischer Catch-up der gestrigen Primetime, der wiederholt angesehen wird.

Der lange Schwanz — verschiedene Kanäle und Archivtage, die jeweils nur wenige ansehen — passt nicht in den Speicher und wird von den Festplatten gelesen. Linux hält mehrfach gelesene Seiten länger, einmalige Ansichten werden vom Schreibstrom innerhalb einer halben bis einer Stunde verdrängt. Daher nimmt der Speicher bei einem Archiv von mehreren zehn Terabyte und einem breiten Publikum den Festplatten in der Regel ein Viertel bis ein Drittel der Lesezugriffe ab: Er beschleunigt das Heißeste, ersetzt aber nicht die Leistung der Festplatten.

2. Lastabschätzung und Wahl der Festplatten¶

Schreiben, Umfang und Lesen¶

Drei Größen werden so berechnet:

Schreibstrom = Anzahl der aufgezeichneten Kanäle × Gesamtbitrate aller Varianten eines Kanals. Zum Beispiel ergeben 150 Kanäle mit je 8 Mbit/s (drei Qualitätsvarianten) 1200 Mbit/s, also 150 MB/s kontinuierliches Schreiben.
Archivumfang = Schreibstrom × Aufbewahrungstiefe. 150 MB/s sind etwa 13 TB pro Tag, 7 Tage etwa 91 TB, 14 Tage etwa 182 TB nutzbarer Speicherplatz, ohne Berücksichtigung von RAID.
Lesestrom = gleichzeitige Archivzuschauer × durchschnittliche Wiedergabebitrate. Die Zahl der Archivzuschauer ist der Spitzenanteil gleichzeitiger Zuschauer, multipliziert mit dem Anteil derer, die das Archiv statt des Live-Signals ansehen. Zum Beispiel: 10 000 Abonnenten, in der Spitze 30 % vor den Bildschirmen und 30 % von ihnen im Archiv — 900 Zuschauer; bei durchschnittlich 4 Mbit/s sind das 3,6 Gbit/s, etwa 450 MB/s Lesen.

Zum Lesestrom von den Festplatten kommt der Schreibstrom hinzu: Die Festplatten bedienen beides gleichzeitig. Einen Teil der Lesezugriffe nimmt der Arbeitsspeicher ab (1. Wie der Knoten das Archiv liest).

HDD und SSD¶

Jeder Archivzuschauer ist ein eigener sequenzieller Lesestrom, und hunderte solcher Ströme zusammen sehen für die Festplatte wie wahlfreier Zugriff mit großen Blöcken aus.

Eine HDD (NL-SAS oder SATA, 7200 U/min) liefert bei vielen gleichzeitigen Strömen in der Regel 60–100 MB/s pro Festplatte, wenn das Read-ahead groß ist (4. Systemabstimmung). Die Kosten pro Terabyte sind bei HDD am niedrigsten.
Eine NVMe-SSD liefert Gigabyte pro Sekunde, wahlfreier Zugriff stört sie nicht. Ein Terabyte kostet um ein Vielfaches mehr. Die Schreibausdauer wird in DWPD angegeben — wie viele volle Festplattenkapazitäten pro Tag während der gesamten Garantiezeit geschrieben werden dürfen. Für das Archiv wird sie so berechnet: tägliches Schreibvolumen ÷ Gesamtkapazität der Festplatten. 13 TB pro Tag auf acht Festplatten zu je 15,36 TB sind etwa 0,1 DWPD, mit Reserve auch für Festplatten mit 1 DWPD.

Beispiel für ein Archiv von 7 Tagen (etwa 91 TB): Ein RAID 6 aus zehn HDD zu je 20 TB ergibt 160 TB nutzbaren Speicherplatz und in der Größenordnung von 500–800 MB/s Gesamtleseleistung. Das genügt für hunderte gleichzeitige Archivzuschauer samt Schreiben. Bei mehr als tausend Archivzuschauern arbeitet ein solches Array am Limit: Es werden weitere Festplatten, ein SSD-Cache (3. SSD-Cache mit Mitteln des Betriebssystems) oder ein Array aus SSD benötigt.

Wahl des RAID und allgemeine Empfehlungen¶

RAID 6 ist die Hauptwahl für große HDD-Arrays: Die Wiederherstellung nach dem Austausch einer 20-TB-Festplatte dauert lange, und RAID 6 übersteht in dieser Zeit den Ausfall einer zweiten Festplatte. RAID 5 wird bei Festplatten dieser Größe nicht empfohlen.
RAID 10 bietet mehr Leistung bei gemischter Last, aber nur die halbe Kapazität.
Für SSD-Arrays eignen sich RAID 5, RAID 6 oder RAID 10: Ihre Wiederherstellungszeit ist deutlich kürzer.
Pro Festplatte oder Array ein Speicher (DVR-Speicher).
Richtwerte für die Wahl:
- bis zu etwa tausend gleichzeitigen Archivzuschauern — ein HDD-Array (RAID 6 oder RAID 10) und 256–512 GB Arbeitsspeicher für den Seitencache;
- mehr Zuschauer oder ein Archiv von 30–90 Tagen mit aktivem Catch-up — HDD für die Kapazität und ein SSD-Cache für den letzten Tag oder die Verteilung der Kanäle auf mehrere Knoten;
- ein reines SSD-Array — wenn Platz im Rack, Energieverbrauch oder sehr hohe Last wichtiger sind als die Kosten pro Terabyte.

3. SSD-Cache mit Mitteln des Betriebssystems¶

Der SSD-Cache stört den Knoten nicht und verlangt von ihm nichts: Der Knoten liest und schreibt Dateien, und der Cache sitzt unterhalb des Dateisystems (Blockebene) oder innerhalb davon. Reihenfolge nach Stärke der Wirkung: zuerst der Arbeitsspeicher (Seitencache), dann die SSD für die heißen Daten der nächsten ein bis zwei Tage (in der Regel 2–8 TB NVMe), dann die HDD für die Kapazität.

Write-through und Write-back¶

Write-through (writethrough) ist der empfohlene Modus für das Archiv. Das Schreiben geht sofort auf die HDD, die SSD hält häufig gelesene Blöcke. Der Ausfall der SSD verliert keine Daten: Das Array arbeitet ohne Cache weiter.
Write-back (writeback) hält auf der SSD auch frisch Geschriebenes, was Timeshift und frischen Catch-up beschleunigt. Aber noch nicht auf die HDD übertragene Daten gehen mit der SSD verloren, daher wird der Cache in diesem Modus nur auf einem Spiegel aus zwei SSD (RAID 1) eingerichtet, und er verbraucht die Schreibausdauer der SSD.
dm-writecache cacht nur das Schreiben und beschleunigt das Lesen des Archivs nicht; für das Archiv ist er nicht geeignet.

lvmcache: RHEL, AlmaLinux, Rocky Linux, Oracle Linux¶

lvmcache (dm-cache) ist die Hauptvariante für Systeme auf Basis von RHEL, wo es regulär unterstützt wird. Der Cache ist ein logischer Datenträger auf der SSD, der mit dem Archivdatenträger in derselben Volume-Gruppe verbunden wird. Die Standardrichtlinie (smq) verlagert Blöcke auf die SSD, die wiederholt gelesen werden, daher verstopfen einmalige Ansichten den Cache nicht. Der Cache lässt sich an einem laufenden Datenträger zu- und abschalten, ohne das Schreiben anzuhalten.

Im Beispiel liegt das Archiv auf dem Datenträger vg_dvr/dvr (HDD-Array), die SSD ist /dev/nvme0n1. Die SSD zur Volume-Gruppe hinzufügen und auf ihr den Cache-Datenträger anlegen:

sudo pvcreate /dev/nvme0n1
sudo vgextend vg_dvr /dev/nvme0n1
sudo lvcreate -n dvr_cache -L 3T vg_dvr /dev/nvme0n1

Den Cache im Write-through-Modus verbinden:

sudo lvconvert --type cache --cachevol dvr_cache --cachemode writethrough vg_dvr/dvr

Modus und Trefferstatistik prüfen:

sudo lvs -o name,size,cache_mode,cache_policy,cache_read_hits,cache_read_misses vg_dvr

Das Verhältnis von cache_read_hits zur Summe aus Treffern und Fehlzugriffen ist der Anteil der Lesezugriffe, den die SSD bedient. Den Cache abschalten: --splitcache lässt den Cache-Datenträger zum erneuten Verbinden bestehen, --uncache löscht ihn; die Archivdaten bleiben in beiden Fällen auf der HDD. In alten LVM-Versionen (zum Beispiel in RHEL 7) gibt es --cachevol nicht: Dort wird der Cache-Datenträger zuerst in einen Pool umgewandelt (lvconvert --type cache-pool) und mit --cachepool verbunden.

sudo lvconvert --splitcache vg_dvr/dvr

bcache: Debian und Ubuntu¶

bcache ist Teil des Linux-Kernels und auf Debian und Ubuntu verbreitet; in RHEL wird es nicht mitgeliefert. Es wird auf leeren Geräten angelegt: Auf einem vorhandenen Array mit Archiv lässt es sich ohne Datenübertragung nicht aktivieren. Das Dateisystem wird erst auf dem Gerät /dev/bcache0 angelegt.

Im Beispiel ist das HDD-Array /dev/md0, die SSD /dev/nvme0n1. Das Gerät mit Cache anlegen (standardmäßig im Write-through-Modus):

sudo apt install bcache-tools
sudo make-bcache -B /dev/md0 -C /dev/nvme0n1

Die wichtigste Einstellung für das Archiv ist sequential_cutoff. Standardmäßig lässt bcache sequenzielles Lesen und Schreiben ab 4 MB am Cache vorbei, und jeder Archivzuschauer ist gerade ein sequenzieller Strom, sodass der Cache mit der Standardeinstellung fast nichts speichert. Den Schwellwert ausschalten:

echo 0 | sudo tee /sys/block/bcache0/bcache/sequential_cutoff

Dieser Wert bleibt nach einem Neustart nicht erhalten: Legen Sie ihn beim Start fest, zum Beispiel mit einer udev-Regel oder einem systemd-Dienst. Modus und Trefferquote prüfen:

cat /sys/block/bcache0/bcache/cache_mode
cat /sys/block/bcache0/bcache/stats_day/cache_hit_ratio

ZFS: ARC und L2ARC¶

In ZFS (OpenZFS-Pakete) übernimmt ein eigener Cache im Speicher die Rolle des Seitencaches — ARC, und die SSD wird als zweite Cache-Ebene an den Pool angebunden — L2ARC. L2ARC cacht nur das Lesen; der Ausfall der SSD verliert keine Daten. Die SSD an den Pool dvr anbinden:

sudo zpool add dvr cache /dev/nvme0n1

Standardmäßig nimmt L2ARC keine Daten auf, die per Read-ahead gelesen wurden, also die sequenziellen Ströme der Archivzuschauer. Für das Archiv muss das ausgeschaltet und ebenfalls für die nächsten Systemstarts gespeichert werden:

echo 0 | sudo tee /sys/module/zfs/parameters/l2arc_noprefetch
echo "options zfs l2arc_noprefetch=0" | sudo tee -a /etc/modprobe.d/zfs.conf

Einige weitere Einstellungen für das Archiv:

recordsize=1M für den Datensatz mit dem Archiv — das Archiv besteht aus großen Dateien, die vollständig gelesen werden;
atime=off — ohne Schreiben der Zugriffszeit bei jedem Lesen;
zfs_arc_max — Grenze des Speichers für ARC; lassen Sie auch dem Knoten Speicher übrig;
l2arc_write_max — Füllgeschwindigkeit des L2ARC; der Standardwert ist klein, und bei einem großen Archiv füllt sich der Cache langsam.

Statistiken zu ARC und L2ARC zeigt arc_summary, die Last auf die Geräte des Pools zpool iostat -v dvr 5.

4. Systemabstimmung¶

Read-ahead. Legen Sie für das HDD-Array ein großes Read-ahead fest, zum Beispiel 4 MB (8192 Sektoren zu je 512 Byte); es bleibt nur bis zum Neustart erhalten, legen Sie es daher auch beim Start fest (mit einer udev-Regel). Für einen LVM-Datenträger bewirkt dasselbe lvchange --readahead.
```
sudo blockdev --setra 8192 /dev/md0
sudo blockdev --getra /dev/md0
```
Speicher für den Cache. Der Seitencache belegt den gesamten freien Speicher, lassen Sie dem Knoten daher eine Reserve: Starten Sie auf ihm keine anderen speicherhungrigen Prozesse und lassen Sie nicht zu, dass das System in den Swap ausweicht. Die Rückgabe von ungenutztem Speicher durch den Knoten ist in Arbeitsspeicher beschrieben.
Dateisystem. Geeignet sind XFS (Standard in Systemen auf Basis von RHEL) und ext4. Binden Sie den Speicher mit noatime ein, damit das Lesen des Archivs keine Schreibzugriffe für die Zugriffszeit erzeugt.
Überwachung. Die Last auf die Festplatten zeigt iostat -x 5 (Spalten für Lesen und Schreiben in MB/s, Wartezeit, Auslastung des Geräts). Die Größe des Seitencaches zeigt die Zeile buff/cache in der Ausgabe von free -h, die Treffer des SSD-Caches zeigen die Befehle aus den obigen Abschnitten. Die Lese- und Schreiblatenzen des Archivs je Stream zeigt der Bildschirm „DVR-Monitor“ (DVR-Monitor), und bei langen Lese- und Schreibvorgängen wird ein Alarm mit Code 50 (dvr-rw-time, Liste der Alarme) ausgelöst.