Was haben LVM und eine Matroschka gemeinsam?

Guten Tag.
Ich möchte meine praktischen Erfahrungen beim Aufbau eines Datenspeichersystems für KVM mit md RAID + LVM mit der Community teilen.

Das Programm wird beinhalten:

• Aufbau von md RAID 1 aus NVMe SSD.
• Aufbau von md RAID 6 aus SATA SSD und herkömmlichen Festplatten.
• Besonderheiten der TRIM/DISCARD-Funktion bei SSD RAID 1/6.
• Erstellung eines bootfähigen md RAID 1/6 Arrays aus einer gemeinsamen Festplattenausstattung.
• Installation des Systems auf NVMe RAID 1 ohne NVMe-Unterstützung im BIOS.
• Verwendung von LVM-Cache und LVM-thin.
• Verwendung von BTRFS-Snapshots und send/receive für Backups.
• Verwendung von LVM-thin-Snapshots und thin_delta für Backups im BTRFS-Stil.

Wenn es Sie interessiert, klicken Sie bitte auf die Fortsetzung.

Haftungsausschluss

Der Autor übernimmt keine Verantwortung für die Folgen der Nutzung oder Nichtnutzung von Materialien/Beispielen/Code/Tipps/Daten aus diesem Artikel. Durch das Lesen oder die Nutzung dieses Materials übernehmen Sie die Verantwortung für alle Folgen dieser Handlungen. Zu den möglichen Folgen gehören:

• Durch die Hitze gebrannte NVMe SSD.
• Vollständig ausgeschöpfter Schreibvorrat und Ausfall von SSDs.
• Vollständiger Datenverlust auf allen Speichermedien, einschließlich Backups.
• Defekte Hardware.
• Verlorene Zeit, Nerven und Geld.
• Alle anderen Folgen, die hier nicht aufgelistet sind.

Hardware

Verfügbar waren:

Mainboard aus dem Jahr 2013 mit Z87-Chipsatz, ausgestattet mit Intel Core i7 / Haswell.

• 4-Kern-Prozessor, 8 Threads
• 32 Gigabyte DDR3-RAM
• 1 x 16 oder 2 x 8 PCIe 3.0
• 1 x 4 + 1 x 1 PCIe 2.0
• 6 x 6 Gbps SATA 3-Anschlüsse

SAS-Adapter LSI SAS9211-8I, umprogrammiert in den IT/HBA-Modus. Die RAID-fähige Firmware wurde absichtlich gegen HBA-Firmware ausgetauscht, damit:

1. Dieser Adapter jederzeit einfach ausgetauscht werden kann.
2. TRIM/DISCARD auf den Festplatten war problemlos, da diese Befehle in der RAID-Firmware gar nicht unterstützt werden, HBA dagegen ist es egal, welche Befehle über den Bus gesendet werden.

8 HDDs — 8 Stück HGST Travelstar 7K1000 mit 1 TB im 2,5-Zoll-Format, wie sie in Notebooks verwendet werden. Diese Disks waren zuvor in einem RAID 6-Array. In dem neuen System finden sie ebenfalls Verwendung, um lokale Backups zu speichern.

Zusätzlich wurde hinzugefügt:

6 SATA SSDs, Modell Samsung 860 QVO 2TB. Von diesen SSDs wurde ein großer Speicherbedarf, SLC-Cache, Zuverlässigkeit und ein niedriger Preis gefordert. Discard/Zero-Unterstützung war Pflicht, die durch eine Zeile in dmesg überprüft wurde:

Kernel: ata1.00: Aktivierung von discard_zeroes_data

2 Stück NVMe SSD Modell Samsung SSD 970 EVO 500GB.

Für diese SSDs sind die Geschwindigkeit beim zufälligen Lesen/Schreiben und ihre Haltbarkeit wichtig. Ein Kühler ist ein Muss. Unbedingt. Sonst – braten Sie sie bei der ersten RAID-Synchronisierung zu einer knusprigen Kruste.

Der StarTech PEX8M2E2 Adapter für 2 x NVMe SSDs, installiert in einem PCIe 3.0 8x Slot. Das ist, wieder, einfach ein HBA, aber für NVMe. Es unterscheidet sich von günstigen Adaptern durch das Fehlen der Anforderung an die Unterstützung von PCIe-Bifurkation durch das Motherboard, da ein integrierter PCIe-Switch vorhanden ist. Es wird sogar in den ältesten Systemen funktionieren, die PCIe haben, selbst wenn es ein x1 PCIe 1.0 Slot ist. Natürlich mit der entsprechenden Geschwindigkeit. Es gibt keine RAID-Funktionen. Es gibt kein integriertes BIOS an Bord. Ihre Systeme werden also nicht magisch lernen, von NVMe zu booten, geschweige denn NVMe RAID mit diesem Gerät zu erstellen.

Dieses Komponente war ausschließlich durch das Vorhandensein nur eines freien 8x PCIe 3.0 Slots im System bedingt, und bei Vorhandensein von 2 freien Slots lässt es sich leicht gegen zwei günstige PEX4M2E1 oder ähnliche Modelle austauschen, die man überall zu Preisen ab 600 Rubel kaufen kann.

Die Absage an jegliche Hardware- oder im Chipset/Bios integrierte RAID-Lösungen wurde bewusst getroffen, um die Möglichkeit zu haben, das gesamte System komplett zu ersetzen, mit Ausnahme der SSDs/HDDs, und alle Daten zu behalten. Idealerweise soll auch das installierte Betriebssystem beim Umstieg auf ganz neue/andere Hardware erhalten bleiben. Hauptsache, es gibt SATA- und PCIe-Ports. Es ist wie eine Live-CD oder ein bootfähiger USB-Stick, nur sehr schnell und etwas voluminös.

HumorWeil, wissen Sie, wie es manchmal ist – manchmal muss man das gesamte Array schnell mitnehmen. Und Daten möchte man nicht verlieren. Zu diesem Zweck sind alle genannten Speichermedien bequem in Schienen im 5.25 Standardgehäuse untergebracht.

Nun, und natürlich für Experimente mit verschiedenen SSD-Caching-Methoden in Linux.

Hardware-RAIDs sind langweilig. Man schaltet sie ein. Es funktioniert oder nicht. Mit mdadm gibt es immer Optionen.

Software

Früher war auf der Hardware Debian 8 Jessie installiert, das nahe am EOL ist. Es wurde ein RAID 6 aus den oben genannten HDDs zusammen mit LVM aufgebaut. Darauf liefen virtuelle Maschinen in kvm/libvirt.

Da der Autor über die geeignete Erfahrung in der Erstellung tragbarer bootfähiger SATA/NVMe-Flashlaufwerke verfügt und um das gewohnte apt-Muster nicht zu stören, wurde als Zielsystem Ubuntu 18.04 gewählt, das bereits ausreichend stabil ist, aber immer noch eine Unterstützung von 3 Jahren in Aussicht hat.

Im genannten System sind alle notwendigen Treiber für unsere Hardware bereits vorinstalliert. Es wird keine zusätzliche Software oder Treiber benötigt.

Vorbereitung zur Installation

Für die Installation des Systems benötigen wir das Ubuntu Desktop-Image. Das Server-System hat einen etwas umständlichen Installer, der übermäßige und nicht abschaltbare Selbstständigkeit aufweist und unbedingt die UEFI-Systempartition auf eine der Festplatten verschiebt, wodurch die gesamte Struktur beeinträchtigt wird. Es wird also nur im UEFI-Modus installiert. Es werden keine anderen Optionen angeboten.

Das ist für uns nicht akzeptabel.

Warum?Leider ist das Booten über UEFI äußerst schlecht mit softwarebasiertem RAID kompatibel, da niemand Reserven für die UEFI-ESP-Partition anbietet. Es gibt im Netz Rezepte, die vorschlagen, die ESP-Partition auf einem USB-Stick zu platzieren, aber das ist ein Ausfallpunkt. Es gibt Rezepte, die mit softwarebasiertem mdadm RAID 1 mit Metadaten der Version 0.9 arbeiten, die es dem UEFI-BIOS ermöglichen, diese Partition zu erkennen, aber das funktioniert nur bis zu dem glücklichen Moment, in dem das BIOS oder ein anderes Betriebssystem auf der Hardware etwas in die ESP Partition schreibt, ohne zuvor mit den anderen Spiegeln zu synchronisieren.

Darüber hinaus hängt das Booten über UEFI von NVRAM ab, das nicht zusammen mit den Festplatten in das neue System migriert wird, da es Teil des Motherboards ist.

Daher werden wir kein neues Rad erfinden. Wir haben bereits ein fertiges, über Jahre bewährtes „Opa-Rad“, das heute Legacy/BIOS-Boot genannt wird und den stolzen Namen CSM auf UEFI-kompatiblen Systemen trägt. Wir werden es einfach vom Regal nehmen, einölen, die Reifen aufpumpen und mit einem feuchten Tuch abwischen.

Die Desktop-Version von Ubuntu kann auch nicht normal mit einem Legacy-Bootloader installiert werden, aber hier gibt es, wie man so schön sagt, immerhin einige Optionen.

Also, stellen wir die Hardware zusammen und laden das System von dem bootfähigen Ubuntu Live-USB-Stick. Wir müssen Pakete herunterladen, also richten wir das Netzwerk ein, das funktioniert. Wenn es nicht funktioniert, können die benötigten Pakete vorher auf den USB-Stick geladen werden.

Wir gehen in die Desktop-Umgebung, starten den Terminal-Emulator, und los geht's:

#sudo bash

Wie…?Die Zeile oben ist der kanonische Auslöser für die hitzigen Debatten über sudo. Mit boMit größeren Möglichkeiten kommt auch eineogrößere Verantwortung. Die Frage ist, ob Sie bereit sind, diese zu übernehmen. Viele glauben, dass die Verwendung von sudo auf diese Weise zumindest unvorsichtig ist. Doch:

#apt-get install mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc

Warum nicht ZFS…?Wenn wir Software auf unseren Computer installieren, leihen wir uns im Wesentlichen die Leistung unserer Hardware von den Entwicklern dieser Software.
Wenn wir diesem Software vertrauen, dass sie unsere Daten sichert, nehmen wir ein Darlehen in Höhe der Kosten für die Wiederherstellung dieser Daten auf, das wir irgendwann begleichen müssen.

Aus dieser Sicht ist ZFS ein Ferrari, während mdadm+lvm mehr einem Fahrrad ähnelt.

Subjektiv zieht der Autor es vor, sich ein unbekanntes Fahrrad auf Kredit zu leihen, anstatt einen Ferrari. Der Preis ist vergleichsweise niedrig. Es gibt keine Führerscheine zu beachten. Die Verkehrsregeln sind einfacher. Parken ist kostenlos. Die Mobilität ist besser. Man kann dem Fahrrad jederzeit Räder anbringen und es lässt sich einfacher selbst reparieren.

Warum dann BTRFS…?Um das Betriebssystem zu laden, benötigen wir ein Dateisystem, das standardmäßig von Legacy/BIOS GRUB unterstützt wird und dabei Live-Snapshots bietet. Wir werden es für die /boot-Partition verwenden. Darüber hinaus zieht der Autor vor, dieses FS für / (Root) zu verwenden, wobei zu beachten ist, dass für jede andere Software separate Partitionen auf LVM erstellt und in die entsprechenden Verzeichnisse eingebunden werden können.

Weder Images virtuelle Maschinen, noch Datenbanken werden wir auf diesem FS speichern.
Dieses FS wird nur dazu verwendet, um sofortige System-Snapshots ohne Abschaltung zu erstellen und diese dann mittels send/receive auf die Backup-Disk zu übertragen.

Darüber hinaus zieht der Autor es vor, die Software auf der Hardware auf ein Minimum zu beschränken und die gesamte andere Software in virtuellen Maschinen auszuführen, unter Verwendung von Features wie der Durchleitung von GPU und PCI-USB-Hauptcontrollern in KVM über IOMMU.

Auf der Hardware verbleiben nur: Datenspeicherung, Virtualisierung und Backup.

Wenn Sie ZFS mehr vertrauen, sind sie prinzipiell für den angegebenen Zweck austauschbar.

Dennoch ignoriert der Autor bewusst die integrierten Funktionen zur Spiegelung / RAID und Redundanz, die in ZFS, BTRFS und LVM vorhanden sind.

Als zusätzliches Argument hat BTRFS die Fähigkeit, zufällige Schreibvorgänge in sequenzielle umzuwandeln, was sich äußerst positiv auf die Geschwindigkeit der Synchronisierung von Snapshots/Sicherungen auf HDDs auswirkt.

Scan aller Geräte neu:

#udevadm control --reload-rules && udevadm trigger

Lassen Sie uns umsehen:

#lsscsi && nvme list
[0:0:0:0] Disk ATA Samsung SSD 860 2B6Q /dev/sda
[1:0:0:0] Disk ATA Samsung SSD 860 2B6Q /dev/sdb
[2:0:0:0] Disk ATA Samsung SSD 860 2B6Q /dev/sdc
[3:0:0:0] Disk ATA Samsung SSD 860 2B6Q /dev/sdd
[4:0:0:0] Disk ATA Samsung SSD 860 2B6Q /dev/sde
[5:0:0:0] Disk ATA Samsung SSD 860 2B6Q /dev/sdf
[6:0:0:0] Disk ATA HGST HTS721010A9 A3J0 /dev/sdg
[6:0:1:0] Disk ATA HGST HTS721010A9 A3J0 /dev/sdh
[6:0:2:0] Disk ATA HGST HTS721010A9 A3J0 /dev/sdi
[6:0:3:0] Disk ATA HGST HTS721010A9 A3B0 /dev/sdj
[6:0:4:0] Disk ATA HGST HTS721010A9 A3B0 /dev/sdk
[6:0:5:0] Disk ATA HGST HTS721010A9 A3B0 /dev/sdl
[6:0:6:0] Disk ATA HGST HTS721010A9 A3J0 /dev/sdm
[6:0:7:0] Disk ATA HGST HTS721010A9 A3J0 /dev/sdn
Knoten SN Modell Namespace Nutzung Format FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 S466NXXXXXXX15L Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7
/dev/nvme1n1 S5H7NXXXXXXX48N Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7


Partitionierung der „Laufwerke“

NVMe SSD

Wir werden sie jedoch nicht partitionieren. Unser BIOS erkennt diese Laufwerke sowieso nicht. Daher werden sie vollständig in ein softwarebasiertes RAID integriert. Wir werden dort nicht einmal Partitionen erstellen. Wenn es dem ‚Kanon‘ oder aus ‚prinzipiellen‘ Gründen entspricht – erstellen Sie eine große Partition wie bei einer HDD.

SATA HDD

Hier braucht man nicht viel zu erfinden. Wir werden eine Partition für alles erstellen. Wir erstellen eine Partition, weil diese Laufwerke vom BIOS erkannt werden und es sogar versuchen kann, davon zu booten. Wir werden später GRUB auf diesen Laufwerken installieren, damit das System plötzlich funktioniert.

#cat >hdd.part << EOF
Bezeichnung: dos
Bezeichnungs-ID: 0x00000000
Gerät: /dev/sdg
Einheit: Sektoren

/dev/sdg1 : start= 2048, size= 1953523120, type=fd, bootable
EOF
#sfdisk /dev/sdg < hdd.part
#sfdisk /dev/sdh < hdd.part
#sfdisk /dev/sdi < hdd.part
#sfdisk /dev/sdj < hdd.part
#sfdisk /dev/sdk < hdd.part
#sfdisk /dev/sdl < hdd.part
#sfdisk /dev/sdm < hdd.part
#sfdisk /dev/sdn < hdd.part

SATA SSD

Hier wird es interessanter.

Erstens sind unsere Laufwerke 2 TB groß. Das liegt im zulässigen Bereich für MBR, was wir nutzen werden. Bei Bedarf kann man auf GPT wechseln. GPT-Laufwerke haben eine Kompatibilitätsebene, die es MBR-kompatiblen Systemen ermöglicht, die ersten 4 Partitionen zu sehen, wenn sie innerhalb der ersten 2 Terabyte liegen. Wichtig ist, dass die bootfähige Partition und die Partition bios_grub am Anfang dieser Laufwerke platziert sind. Das ermöglicht sogar ein Booten von GPT-Laufwerken im Legacy/BIOS-Modus.

Aber das ist nicht unser Fall.

Hier werden wir zwei Partitionen erstellen. Die erste wird 1 GB groß sein und für RAID 1 /boot verwendet werden.

Die zweite wird für RAID 6 verwendet und den gesamten verbleibenden Speicherplatz einnehmen, mit Ausnahme eines kleinen nicht partitionierten Bereichs am Ende des Laufwerks.

Was ist dieser nicht partitionierte Bereich?Laut Quellen im Internet haben unsere SATA SSDs einen dynamisch erweiterbaren SLC-Cache von 6 bis 78 Gigabyte. Die 6 Gigabyte erhalten wir ‚kostenlos‘ durch die Differenz zwischen ‚Gigabyte‘ und ‚Gibibyte‘ im technischen Datenblatt des Laufwerks. Die restlichen 72 Gigabyte stehen aufgrund des ungenutzten Speicherplatzes zur Verfügung.

Hier muss angemerkt werden, dass unser Cache SLC ist und der Platz im 4-Bit-MLC-Modus belegt wird. Das bedeutet für uns effektiv, dass wir für jeweils 4 Gigabyte freien Speicherplatz nur 1 Gigabyte SLC-Cache erhalten.

Wir multiplizieren 72 Gigabyte mit 4 und erhalten 288 Gigabyte. Dies ist der freie Platz, den wir nicht partitionieren werden, um den Laufwerken die volle Nutzung des SLC-Caches zu ermöglichen.

Damit erhalten wir insgesamt bis zu 312 Gigabyte SLC-Cache von sechs Speichermedien effizient. Von allen Speichermedien werden 2 im RAID für Redundanz verwendet.

Eine solche Cachemenge ermöglicht es uns, in der Praxis äußerst selten auf eine Situation zu stoßen, in der die Schreibvorgänge nicht im Cache erfolgen. Das kompensiert äußerst gut den schlimmsten Nachteil von QLC-Speicher, nämlich die extrem niedrige Schreibgeschwindigkeit, wenn Daten am Cache vorbei geschrieben werden. Wenn Ihre Lasten dies nicht unterstützen, empfehle ich Ihnen, ernsthaft darüber nachzudenken, wie lange Ihre SSDs bei dieser Belastung unter Berücksichtigung der TBW im Datenblatt halten werden.

#cat >ssd.part << EOF
Bezeichnung: dos
Bezeichnungs-ID: 0x00000000
Gerät: /dev/sda
Einheit: Sektoren

/dev/sda1 : start= 2048, size= 2097152, type=fd, bootable
/dev/sda2 : start= 2099200, size= 3300950016, type=fd
EOF
#sfdisk /dev/sda < ssd.part
#sfdisk /dev/sdb < ssd.part
#sfdisk /dev/sdc < ssd.part
#sfdisk /dev/sdd < ssd.part
#sfdisk /dev/sde < ssd.part
#sfdisk /dev/sdf < ssd.part

Erstellen von Arrays

Zunächst müssen wir den Computer umbenennen. Das ist notwendig, da der Hostname Teil des Array-Namens irgendwo innerhalb von mdadm ist und dort Einfluss hat. Arrays können natürlich später umbenannt werden, aber das sind überflüssige Schritte.

#mcedit /etc/hostname
#mcedit /etc/hosts
#hostname
vdesk0


NVMe SSD

#mdadm --create --verbose --assume-clean /dev/md0 --level=1 --raid-devices=2 /dev/nvme[0-1]n1

Warum -assume-clean…?Um die Arrays nicht zu initialisieren. Für beide RAID-Stufen 1 und 6 ist dies akzeptabel. Alles kann ohne Initialisierung funktionieren, wenn es sich um ein neues Array handelt. Darüber hinaus ist die Initialisierung eines SSD-Arrays bei der Erstellung eine sinnlose Verschwendung von TBW-Ressourcen. Wir verwenden TRIM/DISCARD, wo immer möglich, auf den geformten SSD-Arrays, um sie "zu initialisieren".

Bei SSD-RAID 1 wird DISCARDED standardmäßig unterstützt.

Bei SSD-RAID 6 muss DISCARDED in den Moduleinstellungen des Kernels aktiviert werden.

Das sollte nur dann gemacht werden, wenn alle SSDs, die in den Arrays der Ebenen 4/5/6 in diesem System verwendet werden, eine funktionierende Unterstützung für discard_zeroes_data haben. Manchmal trifft man auf seltsame Speichergeräte, die dem Kernel die Unterstützung dieser Funktion melden, aber tatsächlich hat es nicht oder funktioniert nicht immer. Im Moment gibt es praktisch überall Unterstützung, jedoch kommen alte Speicher und fehlerhafte Firmware vor. Aus diesem Grund ist die DISCARD-Unterstützung standardmäßig für RAID 6 deaktiviert.

Achtung, der folgende Befehl wird alle Daten auf NVMe-Speichern "initialisieren" und mit "Nullen" überschreiben.

#blkdiscard /dev/md0

Wenn etwas schief geht, versuchen Sie einen Schritt anzugeben.

#blkdiscard --step 65536 /dev/md0

SATA SSD

#mdadm --create --verbose --assume-clean /dev/md1 --level=1 --raid-devices=6 /dev/sd[a-f]1
#blkdiscard /dev/md1
#mdadm --create --verbose --assume-clean /dev/md2 --chunk-size=512 --level=6 --raid-devices=6 /dev/sd[a-f]2

Warum so groß…?Die Erhöhung der Chunk-Größe hat einen positiven Einfluss auf die Geschwindigkeit des zufälligen Lesens von Blöcken bis zu einschließlich der Chunk-Größe. Das liegt daran, dass eine Operation in dieser Größe oder kleiner vollständig auf einem Gerät ausgeführt werden kann. Daher summieren sich die IOPS aller Geräte. Statistisch gesehen überschreiten 99 % der IOs nicht 512K.

Bei RAID 6 sind die Schreib-IOPS geringer oder gleich den IOPS eines einzelnen Laufwerks. Während die IOPS bei zufälligem Lesen um ein Vielfaches höher sein können als bei einem einzelnen Laufwerk, ist die Blockgröße hier entscheidend. immer Der Autor sieht keinen Sinn darin, einen Parameter zu optimieren, der von Design her schlecht ist bei RAID 6, und optimiert stattdessen das, wo sich RAID 6 gut bewährt.
Die schlechten zufälligen Schreiboperationen bei RAID 6 werden wir durch NVMe-Cache und Tricks mit Thin-Provisioning ausgleichen.
Wir haben DISCARD für RAID 6 vorerst nicht aktiviert. Daher werden wir dieses Array momentan nicht "initialisieren". Das machen wir später, nach der Installation des Betriebssystems.

LVM auf NVMe RAID

SATA HDD

#mdadm --create --verbose --assume-clean /dev/md3 --chunk-size=512 --level=6 --raid-devices=8 /dev/sd[g-n]1

Für die Geschwindigkeit möchten wir das Root-Dateisystem auf dem NVMe RAID 1, das /dev/md0 ist, platzieren.

Dennoch benötigen wir dieses schnelle Array auch für andere Zwecke, wie Swap, Metadaten und LVM-Cache sowie LVM-thin-Metadaten. Daher erstellen wir auf diesem Array ein LVM VG.
Wir erstellen eine Partition für das Root-Dateisystem.

#pvcreate /dev/md0
#vgcreate root /dev/md0

Wir erstellen eine Partition für den Swap, die der Größe des Arbeitsspeichers entspricht.

#lvcreate -L 128G --name root root

Installation des Betriebssystems

#lvcreate -L 32G --name swap root

Wir haben alles Notwendige, um das System zu installieren.

Wir starten den Installationsassistenten aus der Ubuntu Live-Umgebung. Normale Installation. Lediglich beim Auswahl der Laufwerke für die Installation muss Folgendes angegeben werden:

Bootloader auf /dev/sda installieren

• /dev/md1, — точка монтирования /boot, ФС — BTRFS
• /dev/root/root (a.k.a /dev/mapper/root-root), — точка монтирования / (корень), ФС — BTRFS
• /dev/root/swap (a.k.a /dev/mapper/root-swap), — использовать как раздел подкачки
• Wenn BTRFS als Root-Dateisystem gewählt wird, erstellt der Installer automatisch zwei BTRFS-Volumes mit den Namen "@" für / (Root) und "@home" für /home.

Wir starten die Installation…

Die Installation endet mit einem modalem Dialogfenster, das über einen Fehler beim Installieren des Bootloaders informiert. Leider kann dieser Dialog nicht auf gewöhnliche Weise verlassen werden, um die Installation fortzusetzen. Wir loggen uns aus der Sitzung aus und loggen uns erneut ein, um auf den sauberen Desktop von Ubuntu Live zu gelangen. Wir öffnen das Terminal und wieder:

Wir erstellen eine chroot-Umgebung, um die Installation fortzusetzen:

#sudo bash

Wir richten das Netzwerk und den Hostnamen in chroot ein:

#mkdir /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@ /dev/mapper/root-root /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@home /dev/mapper/root-root /mnt/chroot/home
#mount -o defaults,space_cache,noatime,nodiratime,discard /dev/md1 /mnt/chroot/boot
#mount --bind /proc /mnt/chroot/proc
#mount --bind /sys /mnt/chroot/sys
#mount --bind /dev /mnt/chroot/dev

Wir betreten die chroot-Umgebung:

#cat /etc/hostname >/mnt/chroot/etc/hostname
#cat /etc/hosts >/mnt/chroot/etc/hosts
#cat /etc/resolv.conf >/mnt/chroot/etc/resolv.conf

Als Erstes installieren wir die Pakete:

#chroot /mnt/chroot

apt-get install --reinstall mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc debsums hdparm

Wir überprüfen und reparieren alle Pakete, die aufgrund einer unvollendeten Systeminstallation fehlerhaft installiert wurden:

Wenn etwas nicht funktioniert hat, müssen Sie möglicherweise zuvor /etc/apt/sources.list bearbeiten.

#CORRUPTED_PACKAGES=$(debsums -s 2>&1 | awk '{print $6}' | uniq)
#apt-get install --reinstall $CORRUPTED_PACKAGES

Wir passen die Parameter für das RAID 6-Modul an, um TRIM/DISCARD zu aktivieren:

Wir nehmen einige Anpassungen an unseren Arrays vor:

#cat >/etc/modprobe.d/raid456.conf << EOF
options raid456 geräte_handhabung_sicher_entfernen=1
EOF

Was war das..?

#cat >/etc/udev/rules.d/60-md.rules << EOF
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="32768"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_min", ATTR{md/sync_speed_min}="48000"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_max", ATTR{md/sync_speed_max}="300000"
EOF
#cat >/etc/udev/rules.d/62-hdparm.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/%k"
EOF
#cat >/etc/udev/rules.d/63-blockdev.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/blockdev --setra 1024 /dev/%k"
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="md*", RUN+="/sbin/blockdev --setra 0 /dev/%k"
EOF

Wir haben eine Sammlung von udev-Regeln erstellt, die Folgendes tun werden:Wir haben eine Sammlung von udev-Regeln erstellt, die Folgendes tun werden:

• Die angemessene Cache-Größe für RAID 6 im Jahr 2020 einstellen. Der Standardwert scheint seit der Einführung von Linux unverändert zu sein und ist seit langem nicht mehr angemessen.
• Reservieren Sie während der Überprüfungen/Synchronisierungen der Arrays mindestens IO. Das ist notwendig, damit Ihre Arrays nicht in einem Zustand dauerhafter Synchronisation unter Last stecken bleiben.
• Begrenzen Sie während der Überprüfungen/Synchronisierungen der Arrays das Maximum an IO. Dies ist notwendig, damit die Synchronisation/Überprüfung der SSD-RAIDs Ihre Speicher nicht zu viel belastet. Besonders relevant für NVMe. (Erinnern Sie sich an den Kühlkörper? Ich habe es nicht im Spaß gemeint.)
• Verbieten Sie über APM den Festplatten das Stoppen des Spins (HDD) und setzen Sie einen Timeout für den Schlafmodus der Festplattencenter auf 7 Stunden. APM kann ganz deaktiviert werden, wenn Ihre Festplatten das unterstützen (-B 255). Bei der Standardeinstellung werden die Festplatten nach fünf Sekunden gestoppt. Dann möchte das OS den Festplattencache zurücksetzen, die Festplatten drehen sich wieder und alles geht von vorne los. Die Festplatten haben eine begrenzte maximale Anzahl an Spins. Ein solcher einfacher Zyklus kann bei den standardmäßig eingestellten 'Notebook'-Festplatten Ihre Laufwerke innerhalb von zwei Jahren leicht ruinieren. Nicht alle Festplatten sind davon betroffen, aber unsere 'Notebook'-Modelle mit den entsprechenden Standardeinstellungen verwandeln RAID in eine schiefe Nachahmung von mini-MAID.
• Stellen Sie den Readahead für rotierende Festplatten auf 1 Megabyte ein – zwei aufeinanderfolgende Blöcke/Chunks für RAID 6.
• Verbieten Sie Readahead auf den Arrays selbst.

Bearbeiten wir /etc/fstab:

#cat >/etc/fstab << EOF
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# file-system mount-point type options dump pass
/dev/mapper/root-root / btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@ 0 1
UUID=$(blkid -o value -s UUID /dev/md1) /boot btrfs defaults,space_cache,noatime,nodiratime,discard 0 2
/dev/mapper/root-root /home btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@home 0 2
/dev/mapper/root-swap none swap sw 0 0
EOF
Warum so..?Wir werden die Partition /boot anhand der UUID suchen, da die Benennung der Arrays theoretisch variieren kann.

Die anderen Partitionen finden wir anhand der LVM-Namen in der Notation /dev/mapper/vg-lv, da sie die Partitionen ausreichend eindeutig identifizieren.

Verwenden Sie UUID nicht für LVM, da die UUIDs von LVM-Volumes und ihren Snapshots übereinstimmen können.Mounten wir /dev/mapper/root-root doppelt..?Ja. Genau so. Eine Besonderheit von BTRFS. Dieses Dateisystem kann mehrmals mit unterschiedlichen Subvolumes gemountet werden.

Aufgrund dieser Besonderheit empfehle ich, niemals LVM-Snapshots aktiver BTRFS-Volumes zu erstellen. Sie könnten bei einem Neustart eine Überraschung erleben.

Regenerieren wir die Konfiguration für mdadm:

#/usr/share/mdadm/mkconf | sed 's/#DEVICE/DEVICE/g' >/etc/mdadm/mdadm.conf

Passen wir die Einstellungen für LVM an:

#cat >>/etc/lvm/lvmlocal.conf << EOF

activation {
thin_pool_autoextend_threshold=90
thin_pool_autoextend_percent=5
}
allocation {
cache_pool_max_chunks=2097152
}
devices {
global_filter=["r|^/dev/.*_corig$|","r|^/dev/.*_cdata$|","r|^/dev/.*_cmeta$|","r|^/dev/.*gpv$|","r|^/dev/images/.*$|","r|^/dev/mapper/images.*$|","r|^/dev/backup/.*$|","r|^/dev/mapper/backup.*$|"]
issue_discards=1
}
EOF

Wir haben eine Sammlung von udev-Regeln erstellt, die Folgendes tun werden:Wir haben die automatische Erweiterung von LVM thin-Pools bei Erreichen von 90 % belegtem Speicherplatz um 5 % des Volumens aktiviert.

Wir haben die maximale Anzahl der Cache-Blöcke für LVM-Cache erhöht.

Wir haben LVM verboten, LVM-Volumes (PV) zu suchen bei:

• Geräten, die LVM-Cache (cdata) enthalten
• Geräten, die über LVM-Cache umgangen werden (<lv_name>_corig). Das gecachte Gerät wird jedoch weiterhin über den Cache (einfach <lv_name>) gescannt.
• Geräten, die LVM-Cache-Metadaten (cmeta) enthalten
• allen Geräten in VG mit dem Namen images. Hier werden wir Images von virtuellen Maschinen haben, und wir wollen nicht, dass LVM auf dem Host die Volumes aktiviert, die der Gast-OS gehören.
• allen Geräten in VG mit dem Namen backup. Hier werden wir Sicherungskopien von Images virtueller Maschinen haben.
• allen Geräten, deren Name mit „gpv“ endet (Guest Physical Volume)

Wir haben die DISCARD-Unterstützung beim Freigeben von nicht verwendetem Speicherplatz auf LVM VG aktiviert. Seien Sie vorsichtig. Dies wird die Löschung von LV auf SSDs erheblich verlängern. Insbesondere gilt dies für SSD RAID 6. Planmäßig werden wir jedoch Thin Provisioning verwenden, sodass das uns überhaupt nicht stören wird.

Aktualisieren wir das initramfs-Image:

#update-initramfs -u -k all

Wir installieren und konfigurieren grub:

#apt-get install grub-pc
#apt-get purge os-prober
#dpkg-reconfigure grub-pc

Welche Festplatten sollten ausgewählt werden?Alle, die sd* sind. Das System sollte in der Lage sein, von jeder funktionierenden SATA-Festplatte oder SSD zu booten.

Warum haben wir os-prober deaktiviert..?Aufgrund von übermäßiger Eigenständigkeit und ungezogenen Händen.

Es funktioniert nicht korrekt, wenn einer der RAID-Arrays in einem degradierten Zustand ist. Es versucht, OS auf Partitionen zu finden, die in virtuellen Maschinen verwendet werden, die auf dieser Hardware laufen.

Wenn Sie es benötigen, können Sie es behalten, aber denken Sie an alles, was oben gesagt wurde. Ich empfehle, nach Lösungen zur Deaktivierung ungezogener Hände im Internet zu suchen.

Damit haben wir die Erstinstallation abgeschlossen. Es ist Zeit, in das gerade installierte OS neu zu starten. Vergessen Sie nicht, die bootfähige Live-CD/USB herauszunehmen.

#exit
#reboot

Als Bootgerät wählen wir irgendeine der SATA SSDs.

LVM auf SATA SSD

Zu diesem Zeitpunkt sind wir bereits ins neue OS gebootet, haben das Netzwerk, apt konfiguriert, ein Terminals Emulator geöffnet und ausgeführt:

#sudo bash

Fahren wir fort.

Wir „initialisieren“ das Array aus SATA SSD:

#blkdiscard /dev/md2

Wenn es nicht funktioniert hat, probieren wir:

#blkdiscard --step 65536 /dev/md2
Wir erstellen LVM VG auf SATA SSD:

#pvcreate /dev/md2
#vgcreate data /dev/md2

Warum noch ein VG..?Tatsächlich haben wir bereits ein VG mit dem Namen root. Warum nicht alles in ein VG hinzufügen?

Wenn es in VG mehrere PV gibt, müssen zur korrekten Aktivierung von VG alle PV vorhanden sein (online). Eine Ausnahme bildet LVM RAID, das wir absichtlich nicht verwenden.

Wir möchten sehr, dass beim Ausfall (d.h. Datenverlust) eines der RAID 6-Array das Betriebssystem ordnungsgemäß bootet und uns die Möglichkeit gibt, das Problem zu lösen.

Zu diesem Zweck werden wir auf der ersten Abstraktionsebene jeden Typ physischer „Datenträger“ in ein separates VG isolieren.

Wenn man es wissenschaftlich betrachtet, gehören verschiedene RAID-Arrays zu unterschiedlichen „Zuverlässigkeitsbereichen“. Es ist nicht ratsam, dafür einen zusätzlichen gemeinsamen Fehlerpunkt zu schaffen, indem man sie in ein VG packt.

Das Vorhandensein von LVM auf der „Hardware“-Ebene ermöglicht es uns, willkürlich Stücke verschiedener RAID-Arrays unterschiedlich zu kombinieren. Zum Beispiel, - zu starten gleichzeitig bcache + LVM thin, bcache + BTRFS, LVM cache + LVM thin, eine komplexe ZFS-Konfiguration mit Caches oder jede andere teuflische Mischung, um all das zu testen und zu vergleichen.

Auf der „Hardware“-Ebene werden wir nichts außer den altbewährten „dicken“ LVM-Volumes verwenden. Eine Ausnahme von dieser Regel könnte möglicherweise die Partition für Backups sein.

Ich denke, bis zu diesem Zeitpunkt haben viele Leser bereits anfängliche Verdachtsmomente bezüglich der Matroschka.

LVM auf SATA HDD

#pvcreate /dev/md3
#vgcreate backup /dev/md3

Wieder eine neue VG..?Wir möchten sehr, dass beim Ausfall des Arrays von Festplatten, das wir für die Datensicherung verwenden, unser Betriebssystem ordnungsgemäß weiterarbeitet und dabei den Zugriff auf nicht gesicherte Daten aufrechterhält. Daher, um Probleme bei der Aktivierung von VG zu vermeiden, erstellen wir ein separates VG.

Einrichtung von LVM Cache

Wir erstellen LV auf NVMe RAID 1, um es als Cache-Gerät zu verwenden.

#lvcreate -L 70871154688B --name cache root

Warum so wenig…?Das liegt daran, dass unsere NVMe SSDs ebenfalls über einen SLC-Cache verfügen. 4 Gigabyte „kostenlos“ und 18 Gigabyte dynamisch durch den belegten Platz im 3-Bit MLC. Nach dem Erschöpfen dieses Caches werden die NVMe SSDs nicht viel schneller sein als unsere SATA SSD mit Cache. Aus diesem Grund macht es für uns keinen Sinn, die LVM Cache-Partition wesentlich größer als das Zweifache des SLC-Cache-Volumens des NVMe-Speichers zu gestalten. Für die verwendeten NVMe-Speicher hält der Autor es für sinnvoll, einen Cache von 32-64 Gigabyte zu erstellen.

Die angegebene Partitiongröße ist erforderlich, um 64 Gigabyte Cache zu organisieren, die Cache-Metadaten zu platzieren und ein Backup der Metadaten zu erstellen.

Zusätzlich möchte ich anmerken, dass nach einem unsachgemäßen Ausschalten des Systems LVM den gesamten Cache als schmutzig markieren und neu synchronisieren wird. Darüber hinaus wird dies bei jeder Verwendung von lvchange auf diesem Gerät bis zu einem Neustart des Systems wiederholt. Daher empfehle ich, den Cache sofort mit dem entsprechenden Skript neu zu erstellen.

Wir erstellen ein LV im SATA RAID 6, um es als Cache-Gerät zu verwenden.

#lvcreate -L 3298543271936B --name cache data

Warum nur drei Terabyte..?Damit man bei Bedarf das SATA SSD RAID 6 für andere Zwecke nutzen kann. Der Speicherplatz für den Cache kann dynamisch und ohne Unterbrechung des Betriebs des Systems erhöht werden. Dafür muss der Cache vorübergehend gestoppt und dann wieder aktiviert werden, aber ein herausragender Vorteil von LVM-cache gegenüber beispielsweise bcache ist, dass dies im laufenden Betrieb möglich ist.

Wir erstellen eine neue VG für das Caching.

#pvcreate /dev/root/cache
#pvcreate /dev/data/cache
#vgcreate cache /dev/root/cache /dev/data/cache

Wir erstellen ein LV auf dem zwischengespeicherten Gerät.

#lvcreate -L 3298539077632B --name cachedata cache /dev/data/cache

Hier haben wir sofort den gesamten freien Speicher auf /dev/data/cache belegt, damit alle anderen benötigten Partitionen sofort auf /dev/root/cache erstellt werden. Wenn etwas nicht dort erstellt wurde, kann es mit pvmove verschoben werden.

Wir erstellen und aktivieren den Cache:

#lvcreate -y -L 64G -n cache cache /dev/root/cache
#lvcreate -y -L 1G -n cachemeta cache /dev/root/cache
#lvconvert -y --type cache-pool --cachemode writeback --chunksize 64k --poolmetadata cache/cachemeta cache/cache
#lvconvert -y --type cache --cachepool cache/cache cache/cachedata

Warum so ein chunksize..?Durch praktische Experimente hat der Autor herausgefunden, dass das beste Ergebnis erzielt wird, wenn die Blockgröße des LVM-Caches mit der Blockgröße des LVM-thin übereinstimmt. Dabei zeigt sich, je kleiner die Größe ist, desto besser funktioniert die Konfiguration bei zufälligen Schreibvorgängen.

64k ist die minimale Blockgröße, die für LVM thin zulässig ist.

Vorsicht writeback..!Ja. Dieser Cachetyp verzögert die Synchronisation von Schreibvorgängen auf das zwischengespeicherte Gerät. Dies kann dazu führen, dass beim Verlust des Caches Daten auf dem zwischengespeicherten Gerät verloren gehen. Später wird der Autor erläutern, welche Maßnahmen zusätzlich zu NVMe RAID 1 ergriffen werden können, um dieses Risiko zu minimieren.

Dieser Cachetyp wurde absichtlich gewählt, um die niedrige Leistung von RAID 6 bei zufälligen Schreibvorgängen auszugleichen.

Überprüfen wir, was wir erreicht haben:

#lvs -a -o lv_name,lv_size,devices --units B cache
LV LSize Geräte
[cache] 68719476736B cache_cdata(0)
[cache_cdata] 68719476736B /dev/root/cache(0)
[cache_cmeta] 1073741824B /dev/root/cache(16384)
cachedata 3298539077632B cachedata_corig(0)
[cachedata_corig] 3298539077632B /dev/data/cache(0)
[lvol0_pmspare] 1073741824B /dev/root/cache(16640)

Auf /dev/data/cache sollte sich nur [cachedata_corig] befinden. Wenn etwas nicht stimmt, verwenden Sie pvmove.

Den Cache bei Bedarf kann man mit einem Befehl deaktivieren:

#lvconvert -y --uncache cache/cachedata

Dies geschieht online. LVM synchronisiert einfach den Cache auf die Festplatte, entfernt ihn und benennt cachedata_corig zurück in cachedata.

Konfiguration von LVM thin

Schätzen wir grob, wie viel Platz wir für die Metadaten von LVM thin benötigen:

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes
thin_metadata_size - geschätzte Metadatenbereichsgröße von 3385794560 Bytes für "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

Runden wir auf 4 Gigabyte auf: 4294967296B

Wir multiplizieren mit zwei und addieren 4194304B für die Metadaten von LVM PV: 8594128896B
Wir erstellen eine separate Partition auf NVMe RAID 1, um die Metadaten von LVM thin und deren Sicherung darauf zu speichern:

#lvcreate -L 8594128896B --name images root

Warum..?Hier könnte sich die Frage stellen, warum man die Metadaten von LVM thin separat speichern sollte, wenn sie ohnehin auf NVMe zwischengespeichert werden und schnell arbeiten.

Die Geschwindigkeit ist zwar wichtig, aber nicht der Hauptgrund. Es geht darum, dass der Cache einen Ausfallpunkt darstellt. Es kann etwas mit ihm passieren, und wenn die Metadaten von LVM thin im Cache gespeichert sind, könnte dies zum vollständigen Verlust aller Daten führen. Ohne vollständige Metadaten wird es nahezu unmöglich sein, die thin Volumes wiederherzustellen.

Indem wir die Metadaten auf ein separates, nicht zwischengespeichertes, aber schnelles Volume verschieben, gewährleisten wir die Sicherheit der Metadaten im Falle eines Verlusts oder einer Beschädigung des Caches. In diesem Fall werden alle durch den Verlust des Caches verursachten Schäden innerhalb der thin Volumes lokalisiert, was die Wiederherstellung erheblich erleichtert. Mit hoher Wahrscheinlichkeit können diese Schäden mithilfe der FS-Protokolle wiederhergestellt werden.

Darüber hinaus, wenn zuvor ein Snapshot des thin Volumes erstellt wurde und der Cache danach mindestens einmal vollständig synchronisiert wurde, wird aufgrund der Besonderheiten der inneren Struktur von LVM thin die Integrität des Snapshots im Falle eines Cache-Verlusts garantiert.

Wir erstellen eine neue VG, die für das Thin-Provisioning verantwortlich ist:

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
Wir erstellen einen Pool:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
Warum -Z yDarüber hinaus, abgesehen von dem Zweck, für den dieser Modus eigentlich gedacht ist — um zu verhindern, dass Daten von einer virtuellen Maschine in eine andere verschüttet werden, wenn der Speicherplatz neu verteilt wird — wird das Zeroing zusätzlich verwendet, um die Geschwindigkeit von Random Writes in Blöcken unter 64k zu erhöhen. Jede Schreiboperation unter 64k in einem zuvor nicht zugewiesenen Bereich des thin Volumes wird in 64K-Cache-ausgerichtete Blöcke umgewandelt. Dies ermöglicht es, die Operation vollständig über den Cache durchzuführen, ohne das zwischengespeicherte Gerät zu verwenden.

Wir verschieben das LV auf die entsprechenden PV:

#pvmove -n images/thin-pool_tdata /dev/root/images /dev/cache/cachedata
#pvmove -n images/lvol0_pmspare /dev/cache/cachedata /dev/root/images
#pvmove -n images/thin-pool_tmeta /dev/cache/cachedata /dev/root/images

Wir überprüfen:

#lvs -a -o lv_name,lv_size,devices --units B images
LV LSize Geräte
[lvol0_pmspare] 4294967296B /dev/root/images(0)
thin-pool 274877906944B thin-pool_tdata(0)
[thin-pool_tdata] 274877906944B /dev/cache/cachedata(0)
[thin-pool_tmeta] 4294967296B /dev/root/images(1024)

Wir erstellen ein thin Volume für Tests:

#lvcreate -V 64G --thin-pool thin-pool --name test images

Wir installieren Pakete für Tests und Überwachung:

#apt-get install sysstat fio

So können wir das Verhalten unserer Speicherkonfiguration in Echtzeit beobachten:

#watch 'lvs --rows --reportformat basic --quiet -ocache_dirty_blocks,cache_settings cache/cachedata && (lvdisplay cache/cachedata | grep Cache) && (sar -p -d 2 1 | grep -E "sd|nvme|DEV|md1|md2|md3|md0" | grep -v Average | sort)'

So können wir unsere Konfiguration testen:

#fio --loops=1 --size=64G --runtime=4 --filename=/dev/images/test --stonewall --ioengine=libaio --direct=1
--name=4kQD32read --bs=4k --iodepth=32 --rw=randread
--name=8kQD32read --bs=8k --iodepth=32 --rw=randread
--name=16kQD32read --bs=16k --iodepth=32 --rw=randread
--name=32KQD32read --bs=32k --iodepth=32 --rw=randread
--name=64KQD32read --bs=64k --iodepth=32 --rw=randread
--name=128KQD32read --bs=128k --iodepth=32 --rw=randread
--name=256KQD32read --bs=256k --iodepth=32 --rw=randread
--name=512KQD32read --bs=512k --iodepth=32 --rw=randread
--name=4Kread --bs=4k --rw=read
--name=8Kread --bs=8k --rw=read
--name=16Kread --bs=16k --rw=read
--name=32Kread --bs=32k --rw=read
--name=64Kread --bs=64k --rw=read
--name=128Kread --bs=128k --rw=read
--name=256Kread --bs=256k --rw=read
--name=512Kread --bs=512k --rw=read
--name=Seqread --bs=1m --rw=read
--name=Longread --bs=8m --rw=read
--name=Longwrite --bs=8m --rw=write
--name=Seqwrite --bs=1m --rw=write
--name=512Kwrite --bs=512k --rw=write
--name=256write --bs=256k --rw=write
--name=128write --bs=128k --rw=write
--name=64write --bs=64k --rw=write
--name=32write --bs=32k --rw=write
--name=16write --bs=16k --rw=write
--name=8write --bs=8k --rw=write
--name=4write --bs=4k --rw=write
--name=512KQD32write --bs=512k --iodepth=32 --rw=randwrite
--name=256KQD32write --bs=256k --iodepth=32 --rw=randwrite
--name=128KQD32write --bs=128k --iodepth=32 --rw=randwrite
--name=64KQD32write --bs=64k --iodepth=32 --rw=randwrite
--name=32KQD32write --bs=32k --iodepth=32 --rw=randwrite
--name=16KQD32write --bs=16k --iodepth=32 --rw=randwrite
--name=8KQD32write --bs=8k --iodepth=32 --rw=randwrite
--name=4kQD32write --bs=4k --iodepth=32 --rw=randwrite
| grep -E 'read|write|test' | grep -v ioengine

Vorsicht! Ressource!Dieser Code führt 36 verschiedene Tests durch, von denen jeder 4 Sekunden dauert. Die Hälfte der Tests ist auf das Schreiben ausgerichtet. In 4 Sekunden kann man auf NVMe sehr viel schreiben. Bis zu 3 Gigabyte pro Sekunde. Daher kann jeder Start eines Schreibtests bis zu 216 Gigabyte SSD-Ressourcen beanspruchen.

Lesen und Schreiben gemischt?Ja. Es macht Sinn, Lese- und Schreibtests separat durchzuführen. Darüber hinaus ist es sinnvoll, sicherzustellen, dass alle Caches synchronisiert sind, damit frühere Schreibvorgänge das Lesen nicht beeinflussen.

Die Ergebnisse werden beim ersten Durchlauf stark variieren und mit den folgenden Durchläufen, da sich die Caches und das Thin-Provisioning füllen, sowie abhängig davon, ob das System die bei der vorherigen Ausführung gefüllten Caches synchronisieren konnte.

Nebenbei empfehle ich, die Geschwindigkeit auf einem bereits gefüllten Thin-Provisioned Volume zu messen, von dem gerade ein Snapshot erstellt wurde. Der Autor hatte die Möglichkeit zu beobachten, wie sich zufällige Schreibvorgänge direkt nach der Erstellung des ersten Snapshots deutlich beschleunigen, insbesondere wenn der Cache noch nicht vollständig gefüllt ist. Dies geschieht dank der Copy-on-Write-Semantik, der Blockausrichtung von Cache und Thin Volume und der Tatsache, dass zufälliges Schreiben auf RAID 6 in zufälliges Lesen auf RAID 6 umschlägt, gefolgt von einer Schreiboperation in den Cache. In unserer Konfiguration ist zufälliges Lesen mit RAID 6 bis zu 6-mal (Anzahl der SATA SSDs im Array) schneller als Schreiben. Da die Blöcke für CoW sequenziell aus dem Thin-Pool zugewiesen werden, wird das Schreiben größtenteils ebenfalls in sequentielles Schreiben umgewandelt.

Beide diese Eigenschaften können vorteilhaft genutzt werden.

Cache-„kohärente“ Snapshots

Um das Risiko von Datenverlusten im Falle einer Beschädigung oder eines Verlustes des Caches zu verringern, schlägt der Autor vor, eine Praxis der Snapshot-Rotation einzuführen, die deren Integrität in diesem Fall gewährleistet.

Erstens, da die Metadaten der Thin Volumes auf einem nicht-cached Gerät gespeichert sind, bleiben die Metadaten integer, und potenzielle Verluste werden innerhalb der Dateneinheiten isoliert.

Der nächste Rotationszyklus der Snapshots garantiert die Datenintegrität innerhalb der Snapshots im Falle eines Cacheverlustes:

1. Für jedes Thin Volume mit dem Namen erstellen wir einen Snapshot mit dem Namen .cached
2. Wir setzen den Migration Threshold auf einen vernünftig hohen Wert: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
3. Im Zyklus überprüfen wir die Anzahl der schmutzigen Blöcke im Cache: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' Wir warten, bis wir Null erhalten. Wenn es zu lange dauert, um Null zu erreichen, kann temporär der Cache in den Writethrough-Modus versetzt werden. Allerdings, angesichts der Geschwindigkeitseigenschaften unserer SATA- und NVMe-SSD-Arrays sowie deren TBW-Ressourcen, werden Sie entweder schnell genug den Moment erfassen können, ohne den Cache-Modus zu ändern, oder Ihre Hardware wird ihren gesamten Ressourcen innerhalb weniger Tage verbrauchen. Aufgrund der Ressourcenbeschränkungen ist das System grundsätzlich nicht in der Lage, ständig unter 100% Schreiblast zu laufen. Unsere NVMe-SSDs werden bei 100% Schreiblast ihre Ressourcen vollständig aufbrauchen in 3-4 Tagen. SATA-SSDs leben nur etwa doppelt so lange. Daher gehen wir davon aus, dass der Großteil der Last auf dem Lesen liegt, während wir beim Schreiben relativ kurze, extrem hohe Aktivitätsanstiege in Kombination mit einer geringen durchschnittlichen Last haben.
4. Sobald wir Null erreicht haben (oder erstellt haben), benennen wir <name>.cached in <name>.committed um. Die alte <name>.committed wird gelöscht.
5. Optional, wenn der Cache zu 100% gefüllt ist, kann er mit einem Skript recreated werden, um ihn somit zu leeren. Mit einem halb leeren Cache funktioniert das System deutlich schneller beim Schreiben.
6. Wir setzen die Migration Threshold auf Null: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata Dies wird vorübergehend das Synchronisieren des Caches auf das primäre Medium verhindern.
7. Wir warten, bis sich genug Änderungen im Cache angesammelt haben #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' oder der Timer ausgelöst wird.
8. Wiederholen wir das Ganze.

Warum die Komplexität mit dem Migration Threshold…?Die Sache ist, dass in der Praxis ‚zufälliges‘ Schreiben tatsächlich nicht ganz zufällig ist. Wenn wir etwas in einen Sektor von 4 Kilobyte schreiben, besteht eine hohe Wahrscheinlichkeit, dass in den nächsten paar Minuten in diesen oder einen der benachbarten (+- 32K) Sektoren ebenfalls geschrieben wird.

Indem wir die Migration Threshold auf Null setzen, verzögern wir das Synchronisieren des Schreibens auf die SATA-SSDs und aggregieren mehrere Änderungen eines 64K-Blocks im Cache. Dadurch wird die Ressource der SATA-SSDs deutlich gespart.

Und wo ist der Code..?Leider hält der Autor sich für nicht kompetent genug in Bezug auf die Entwicklung von Bash-Skripten, da er 100% autodidaktisch ist und ‚google‘-getriebenes Development praktiziert, weshalb er denkt, dass der schreckliche Code, der aus seinen Händen kommt, von niemandem sonst verwendet werden sollte.

Ich denke, die Fachleute in diesem Bereich können die oben beschriebene Logik bei Bedarf selbst umsetzen und vielleicht sogar ansprechend als systemd-Service gestalten, wie es der Autor versucht hat.

Ein solches einfaches Schema zur Rotation von Snapshots ermöglicht es uns, dauerhaft einen vollständig synchronisierten Snapshot auf einem SATA-SSD zu haben. Darüber hinaus können wir mit dem Tool thin_delta herausfinden, welche Blöcke nach seiner Erstellung geändert wurden, und somit Beschädigungen auf den Hauptvolumen lokalisieren, was die Wiederherstellung erheblich vereinfacht.

TRIM/DISCARD in libvirt/KVM

Da der Datenspeicher für KVM unter libvirt verwendet wird, wäre es vorteilhaft, unsere VMs so zu konfigurieren, dass sie nicht nur den kostenlosen Speicherplatz belegen, sondern auch den bereits nicht mehr benötigten Speicher wieder freigeben.

Dies erfolgt durch Emulation der TRIM/DISCARD-Unterstützung auf virtuellen Festplatten. Dazu muss der Controller-Typ auf virtio-scsi geändert und die XML bearbeitet werden.

#virsh edit vmname
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='writethrough' io='threads' discard='unmap'/>
<source dev='/dev/images/vmname'/>
<backingStore/>
<target dev='sda' bus='scsi'/>
<alias name='scsi0-0-0-0'/>