Viel freier RAM, NVMe Intel P4500 und alles ist extrem langsam – die Geschichte des erfolglosen Hinzufügens einer Swap-Partition

In diesem Artikel werde ich über eine Situation sprechen, die kürzlich bei einem der Server in unserer VPS-Cloud aufgetreten ist und mich mehrere Stunden lang ratlos gemacht hat. Ich konfiguriere und behebe seit etwa 15 Jahren Linux-Server, aber dieser Fall passt überhaupt nicht in meine Praxis – ich habe mehrere falsche Annahmen gemacht und war ein wenig verzweifelt, bevor ich die Ursache des Problems richtig ermitteln und lösen konnte .

Präambel

Wir betreiben eine mittelgroße Cloud, die wir auf Standardservern mit folgender Konfiguration aufbauen: 32 Kerne, 256 GB RAM und ein 4500 TB PCI-E Intel P4 NVMe-Laufwerk. Diese Konfiguration gefällt uns sehr gut, da sie die Sorge um den E/A-Overhead überflüssig macht, indem sie die korrekte Einschränkung auf der Ebene des VM-Instanztyps bereitstellt. Weil NVMe Intel P4500 Dank der beeindruckenden Leistung können wir gleichzeitig sowohl die vollständige IOPS-Bereitstellung für Maschinen als auch den Backup-Speicher auf einem Backup-Server ohne IOWAIT bereitstellen.

Wir gehören zu den Altgläubigen, die kein hyperkonvergentes SDN und andere stilvolle, modische, jugendliche Dinge zum Speichern von VM-Volumes verwenden, und glauben, dass es umso einfacher ist, Fehler zu beheben, je einfacher das System ist, wenn „der Haupt-Guru weg ist“. ins Gebirge." Daher speichern wir VM-Volumes im QCOW2-Format in XFS oder EXT4, das auf LVM2 bereitgestellt wird.

Wir werden auch durch das Produkt, das wir für die Orchestrierung verwenden – Apache CloudStack – zur Verwendung von QCOW2 gezwungen.

Um ein Backup durchzuführen, erstellen wir ein vollständiges Image des Volumes als LVM2-Snapshot (ja, wir wissen, dass LVM2-Snapshots langsam sind, aber auch hier hilft uns der Intel P4500). Wir machen lvmcreate -s .. und mit der Hilfe dd Wir senden die Sicherungskopie an einen Remote-Server mit ZFS-Speicher. Hier sind wir noch etwas fortschrittlich – schließlich kann ZFS Daten in komprimierter Form speichern und wir können sie mit schnell wiederherstellen DD oder einzelne VM-Volumes nutzen mount -o loop ....

Sie können natürlich nicht das vollständige Image des LVM2-Volumes entfernen, sondern das Dateisystem darin mounten RO und die QCOW2-Images selbst zu kopieren, mussten wir jedoch feststellen, dass XFS dadurch schlecht wurde, und zwar nicht sofort, sondern auf unvorhersehbare Weise. Wir mögen es wirklich nicht, wenn Hypervisor-Hosts an Wochenenden, in der Nacht oder an Feiertagen aufgrund von Fehlern, von denen nicht klar ist, wann sie auftreten, plötzlich „hängen bleiben“. Daher verwenden wir für XFS kein Snapshot-Mounting RO Um Volumes zu extrahieren, kopieren wir einfach das gesamte LVM2-Volume.

Die Geschwindigkeit der Sicherung auf den Backup-Server wird in unserem Fall durch die Leistung des Backup-Servers bestimmt, die bei inkompressiblen Daten bei etwa 600-800 MB/s liegt; ein weiterer Limiter ist der 10Gbit/s-Kanal, mit dem der Backup-Server verbunden ist zum Cluster.

In diesem Fall werden Sicherungskopien von 8 Hypervisor-Servern gleichzeitig auf einen Sicherungsserver hochgeladen. Da die Festplatten- und Netzwerksubsysteme des Backup-Servers langsamer sind, kann es daher nicht zu einer Überlastung der Festplattensubsysteme der Hypervisor-Hosts kommen, da diese einfach nicht in der Lage sind, beispielsweise 8 GB/s zu verarbeiten, was die Hypervisor-Hosts problemlos können produzieren.

Der obige Kopiervorgang ist für die weitere Geschichte sehr wichtig, einschließlich der Details – Verwendung eines schnellen Intel P4500-Laufwerks, Verwendung von NFS und wahrscheinlich auch der Verwendung von ZFS.

Backup-Geschichte

Auf jedem Hypervisor-Knoten haben wir eine kleine SWAP-Partition mit einer Größe von 8 GB, und wir „rollen“ den Hypervisor-Knoten selbst aus DD vom Referenzbild. Für das Systemvolumen auf Servern verwenden wir 2xSATA SSD RAID1 oder 2xSAS HDD RAID1 auf einem LSI- oder HP-Hardware-Controller. Im Allgemeinen ist es uns völlig egal, was sich darin befindet, da unser Systemvolume mit Ausnahme von SWAP im „fast schreibgeschützten“ Modus arbeitet. Und da wir viel RAM auf dem Server haben und dieser zu 30-40 % frei ist, denken wir nicht über SWAP nach.

Backup-Prozess. Diese Aufgabe sieht in etwa so aus:

#!/bin/bash

mkdir -p /mnt/backups/volumes

DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)

lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snap

Beachten Sie die ionice -c3Tatsächlich ist dieses Ding für NVMe-Geräte völlig nutzlos, da der E/A-Planer für sie wie folgt eingestellt ist:

cat /sys/block/nvme0n1/queue/scheduler
[none] 

Wir haben jedoch eine Reihe von Legacy-Knoten mit herkömmlichen SSD-RAIDs, für die dies relevant ist und die daher umziehen WIE ES IST. Insgesamt ist dies nur ein interessanter Code, der die Sinnlosigkeit erklärt ionice im Falle einer solchen Konfiguration.

Achten Sie auf die Flagge iflag=direct für DD. Wir verwenden direkte E/A unter Umgehung des Puffercaches, um einen unnötigen Austausch von E/A-Puffer beim Lesen zu vermeiden. Jedoch, oflag=direct Wir tun dies nicht, da wir bei der Verwendung von ZFS auf Leistungsprobleme gestoßen sind.

Wir nutzen dieses Schema seit mehreren Jahren erfolgreich und ohne Probleme.

Und dann fing es an... Wir haben festgestellt, dass einer der Knoten nicht mehr gesichert war und der vorherige mit einem monströsen IOWAIT von 50 % lief. Beim Versuch zu verstehen, warum das Kopieren nicht erfolgt, sind wir auf das folgende Phänomen gestoßen:

Volume group "images" not found

Wir dachten darüber nach: „Das Ende des Intel P4500 ist gekommen“, doch bevor der Server ausgeschaltet wurde, um das Laufwerk auszutauschen, musste noch ein Backup durchgeführt werden. Wir haben LVM2 behoben, indem wir Metadaten aus einem LVM2-Backup wiederhergestellt haben:

vgcfgrestore images

Wir haben ein Backup gestartet und dieses Ölgemälde gesehen:

Wieder waren wir sehr traurig – es war klar, dass wir so nicht leben könnten, da alle VPS leiden würden, was bedeutet, dass auch wir leiden würden. Was passiert ist, ist völlig unklar - iostat zeigte erbärmliche IOPS und den höchsten IOWAIT. Es gab keine anderen Ideen als „Lasst uns NVMe ersetzen“, aber die Erkenntnis kam gerade noch rechtzeitig.

Analyse der Situation Schritt für Schritt

Historisches Magazin. Einige Tage zuvor war es notwendig, auf diesem Server einen großen VPS mit 128 GB RAM zu erstellen. Es schien genügend Speicher vorhanden zu sein, aber um auf der sicheren Seite zu sein, haben wir der Swap-Partition weitere 32 GB zugewiesen. Der VPS wurde erstellt, hat seine Aufgabe erfolgreich abgeschlossen und der Vorfall wurde vergessen, aber die SWAP-Partition blieb bestehen.

Konfigurationsfunktionen. Für alle Cloud-Server der Parameter vm.swappiness wurde auf Standard gesetzt 60. Und SWAP wurde auf SAS HDD RAID1 erstellt.

Was ist passiert (laut Redaktion). Beim Sichern DD erzeugte viele Schreibdaten, die vor dem Schreiben in NFS in RAM-Puffer abgelegt wurden. Systemkern, richtliniengesteuert swappiness, verschob viele Seiten des VPS-Speichers in den Swap-Bereich, der sich auf einem langsamen HDD-RAID1-Volume befand. Dies führte dazu, dass IOWAIT sehr stark wuchs, allerdings nicht aufgrund von IO NVMe, sondern aufgrund von IO HDD RAID1.

Wie das Problem gelöst wurde. Die 32-GB-Swap-Partition wurde deaktiviert. Dies hat 16 Stunden gedauert; Sie können separat nachlesen, wie und warum sich SWAP so langsam abschaltet. Einstellungen wurden geändert swappiness auf einen Wert gleich 5 überall in der Wolke.

Wie konnte das nicht passieren?. Erstens, wenn SWAP auf einem SSD-RAID- oder NVMe-Gerät wäre, und zweitens, wenn es kein NVMe-Gerät gäbe, sondern ein langsameres Gerät, das kein solches Datenvolumen erzeugen würde – ironischerweise trat das Problem auf, weil dieses NVMe zu schnell ist.

Danach begann alles wie zuvor zu funktionieren – ohne IOWAIT.

Source: habr.com