Viel freier RAM, NVMe Intel P4500 und alles stockt heftig – eine Geschichte über misslungene Hinzufügung eines Swap-Bereichs

In diesem Artikel werde ich über eine Situation berichten, die kürzlich mit einem unserer VPS-Cloud-Server passiert ist und mich für mehrere Stunden vor ein Rätsel stellte. Ich beschäftige mich seit etwa 15 Jahren mit der Konfiguration und Fehlersuche von Linux-Servern, aber dieser Fall passt überhaupt nicht in meine Praxis – ich habe einige falsche Annahmen getroffen und war ein wenig verzweifelt, bevor ich in der Lage war, die Ursache des Problems richtig zu bestimmen und es zu lösen.

Präambel

Wir betreiben eine mittelgroße Cloud, die wir auf Standardservern mit der folgenden Konfiguration aufbauen – 32 Kerne, 256 GB RAM und ein NVMe-PCI-E-Intel-P4500-Speicher mit einer Größe von 4 TB. Wir sind sehr mit dieser Konfiguration zufrieden, da sie es uns ermöglicht, uns keine Sorgen über IO-Mangel zu machen und ein korrektes Limit auf VM-Instanzebene zu gewährleisten. Da das NVMe-Intel P4500 beeindruckende Leistung bietet, können wir sowohl vollständige IOPS-Anforderungen für Maschinen als auch die Sicherung des Speichers auf einen Backup-Server mit null IOWAIT gleichzeitig bereitstellen.

Wir gehören zu den traditionellen Betreibern, die keine hyperkonvergenten SDN und andere schicke, trendige, jugendliche Dinge zum Speichern von VM-Volumes verwenden, da wir der Meinung sind, dass je einfacher das System ist, desto einfacher ist es, es unter Bedingungen wie "der Hauptguru ist in die Berge gegangen" zu beheben. Daher speichern wir VM-Volumes im QCOW2-Format in XFS oder EXT4, das auf LVM2 bereitgestellt wird.

Die Notwendigkeit, QCOW2 zu verwenden, ergibt sich auch aus dem Produkt, das wir für die Orchestrierung verwenden – Apache CloudStack.

Für die Durchführung von Backups erstellen wir ein vollständiges Abbild des Volumes als LVM2-Snapshot (ja, wir wissen, dass LVM2-Snapshots langsam sind, aber der Intel P4500 hilft uns auch hier). Wir machen lvmcreate -s .. und senden das Backup mit dd auf einen entfernten Server mit ZFS-Speicher. Hier sind wir doch ein wenig fortschrittlich – ZFS kann schließlich Daten in komprimierter Form speichern, und wir können sie schnell wiederherstellen mit DD oder einzelne VM-Volumes mit mount -o loop ....

Es ist natürlich auch möglich, kein vollständiges Abbild des LVM2-Volumes zu erstellen, sondern das Dateisystem im RO-Modus zu mounten. und die QCOW2-Images selbst zu kopieren, allerdings hatten wir festgestellt, dass XFS darunter leidet, und zwar nicht sofort, sondern unvorhersehbar. Wir mögen es überhaupt nicht, wenn die Hypervisor-Hosts an Wochenenden, nachts oder an Feiertagen plötzlich "einfrieren" aufgrund von Fehlern, die unklar sind, wann sie auftreten werden. Daher nutzen wir für XFS keine Snapshot-Montierung im Modus RO-Modus zu mounten. zur Extraktion von Volumes, sondern kopieren einfach das gesamte LVM2-Volume.

Die Geschwindigkeit der Datensicherung auf dem Backup-Server hängt in unserem Fall von der Leistung des Backup-Servers ab, die etwa 600-800 MB/s für nicht komprimierte Daten beträgt, und der weitere Begrenzungsfaktor ist die 10Gbit/s-Leitung, über die der Backup-Server mit dem Cluster verbunden ist.

Insgesamt laden 8 Server Hypervisoren gleichzeitig auf einen Backup-Server die Backups hoch. Somit verhindern die langsameren Speicher- und Netzwerksubsysteme des Backup-Servers, dass die Speichersubsysteme der Hypervisor-Hosts überlastet werden, da sie einfach nicht in der Lage sind, sagen wir, 8 GB/s zu verarbeiten, die die Hypervisor-Hosts problemlos bereitstellen können.

Der oben beschriebene Kopiervorgang ist sehr wichtig für die weitere Erzählung, einschließlich der Details — die Verwendung des schnellen Intel P4500-Speichers, die Nutzung von NFS und wahrscheinlich die Verwendung von ZFS.

Geschichte der Datensicherung

An jedem Hypervisor-Knoten haben wir eine kleine SWAP-Partition mit einer Größe von 8 GB, und den Hypervisor-Knoten "rollen" wir mit Hilfe von DD aus einem Referenz-Image aus. Für das Systemvolume auf den Servern verwenden wir 2xSATA SSD RAID1 oder 2xSAS HDD RAID1 mit einem Hardware-Controller von LSI oder HP. Im Allgemeinen ist es uns völlig egal, was da drin ist, da unser Systemvolume im "fast readonly"-Modus funktioniert, mit Ausnahme des SWAPs. Da wir sehr viel RAM auf dem Server haben und dieser zu 30-40% frei ist, denken wir nicht an SWAP.

Der Prozess der Datensicherung. Diese Aufgabe sieht ungefähr 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

Achten Sie darauf, dass ionice -c3, tatsächlich ist dieses Tool für NVMe-Geräte völlig nutzlos, da der IO-Scheduler für sie wie folgt eingestellt ist:

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

Aber wir haben eine Reihe von Legacy-Knoten mit normalen SSD-RAIDs, für sie ist das relevant, und so migriert es AS IS. Im Allgemeinen ist dies einfach ein interessanter Codeausschnitt, der die Sinnlosigkeit erklärt ionice bei einer solchen Konfiguration.

Achten Sie auf das Flag iflag=direct für DD. Wir verwenden Direct IO, um den Puffer Cache zu umgehen, um keine unnötigen IO-Pufferwechsel beim Lesen vorzunehmen. Allerdings, oflag=direct tun wir das nicht, da wir auf Leistungsprobleme mit ZFS gestoßen sind, als wir es verwendet haben.

Dieses Schema setzen wir seit mehreren Jahren erfolgreich ohne Probleme ein.

Und dann begann es… Wir stellten fest, dass für einen der Knoten die Sicherung nicht mehr funktionierte und die vorherige mit einem schrecklichen IOWAIT von fast 50% durchgeführt wurde. Als wir versuchten zu verstehen, warum die Sicherung nicht stattfand, stießen wir auf das Phänomen:

Volume group "images" nicht gefunden

Wir dachten über "das Ende von Intel P4500" nach, allerdings musste vor dem Abschalten des Servers zum Austausch des Laufwerks unbedingt noch eine Sicherung durchgeführt werden. Wir reparierten LVM2 mithilfe der Wiederherstellung von Metadaten aus dem LVM2-Backup:

vgcfgrestore images

Wir starteten die Sicherung und sahen folgendes Bild:

Wir waren wieder sehr traurig – es war klar, dass so ein Zustand nicht tragbar war, da alle VPS leiden würden, und damit auch wir. Was passiert war, war völlig unklar – iostat zeigte mickrige IOPS und extrem hohes IOWAIT. Es gab keine Ideen, außer "lasst uns das NVMe ersetzen", aber rechtzeitig kam die Erleuchtung.

Situation Schritt für Schritt analysieren

Historisches Protokoll. Einige Tage zuvor war es auf diesem Server erforderlich, eine große VPS mit 128 GB RAM zu erstellen. Der Speicher schien ausreichen, aber zur Sicherheit wurden 32 GB für die Swap-Partition bereitgestellt. Die VPS wurde erstellt, erledigte erfolgreich ihre Aufgabe und der Vorfall wurde vergessen, während die SWAP-Partition bestehen blieb.

Konfigurationsmerkmale. Für alle Cloud-Server war der Parameter vm.swappiness auf den Standardwert 60gesetzt.

Und die SWAP-Partition wurde auf einem SAS HDD RAID1 erstellt.Was passierte (nach Meinung der Redaktion) DD . Bei der Sicherung wurden viele Daten zum Schreiben ausgegeben, die vor dem Schreiben in NFS in RAM-Puffer gelangten. Der Kernel des Systems verschob, gestützt auf die Politik derswappiness

, viele Seiten des VPS-Speichers in den Swap-Bereich, der sich auf dem langsamen HDD RAID1-Volumen befand. Dies führte dazu, dass IOWAIT stark anstieg, allerdings nicht wegen IO NVMe, sondern wegen IO HDD RAID1.Wie das Problem gelöst wurde wurden viele Daten zum Schreiben ausgegeben, die vor dem Schreiben in NFS in RAM-Puffer gelangten. Der Kernel des Systems verschob, gestützt auf die Politik der . Die 32-GB-Swap-Partition wurde deaktiviert. Dies dauerte 16 Stunden; darüber, wie und warum SWAP so langsam deaktiviert wird, kann man separat lesen. Die Parameter wurden geändert 5 auf einen Wert von

im gesamten Cloud-Netzwerk geändert. Wie es dazu kommen konnte.. Erstens, wenn SWAP auf einem SSD-RAID oder NVMe-Gerät wäre, und zweitens, wenn kein NVMe-Gerät vorhanden wäre, sondern ein langsameres Gerät, das nicht so viel Daten ausgeben kann – ironischerweise trat das Problem auf, weil NVMe zu schnell ist.

Nach diesem stellte sich alles wieder so ein wie zuvor – mit null IOWAIT.

Quelle: habr.com