En masse gratis RAM, NVMe Intel P4500 og alt er ekstremt langsomt - historien om den mislykkede tilføjelse af en swap-partition

I denne artikel vil jeg tale om en situation, der for nylig opstod med en af ​​serverne i vores VPS-sky, som efterlod mig i adskillige timer. Jeg har konfigureret og fejlsøgt Linux-servere i omkring 15 år, men denne sag passer slet ikke ind i min praksis - jeg lavede flere falske antagelser og blev lidt desperat, før jeg var i stand til korrekt at fastslå årsagen til problemet og løse det .

præambel

Vi driver en mellemstor sky, som vi bygger på standardservere med følgende konfiguration - 32 kerner, 256 GB RAM og et 4500TB PCI-E Intel P4 NVMe-drev. Vi kan virkelig godt lide denne konfiguration, fordi den eliminerer behovet for at bekymre sig om IO-overhead ved at give den korrekte begrænsning på VM-instanstypeniveau. Fordi NVMe Intel P4500 har imponerende ydeevne, kan vi samtidig levere både fuld IOPS-forsyning til maskiner og backup-lager til en backup-server med nul IOWAIT.

Vi er en af ​​de gamle troende, der ikke bruger hyperkonvergeret SDN og andre stilfulde, moderigtige ungdomsting til at gemme VM-volumener, idet vi tror, ​​at jo enklere systemet er, jo lettere er det at fejlfinde det under betingelserne, hvor "hovedguruen er gået til bjergene." Som et resultat gemmer vi VM-volumener i QCOW2-format i XFS eller EXT4, som er installeret oven på LVM2.

Vi er også tvunget til at bruge QCOW2 af det produkt, vi bruger til orkestrering - Apache CloudStack.

For at udføre en backup tager vi et fuldt billede af volumen som et LVM2-snapshot (ja, vi ved, at LVM2-snapshots er langsomme, men Intel P4500 hjælper os også her). Det gør vi lvmcreate -s .. og med hjælp dd vi sender sikkerhedskopien til en ekstern server med ZFS-lagring. Her er vi stadig lidt progressive - ZFS kan trods alt gemme data i komprimeret form, og vi kan hurtigt gendanne dem vha. DD eller få individuelle VM-volumener ved hjælp af mount -o loop ....

Du kan selvfølgelig ikke fjerne hele billedet af LVM2-volumenet, men montere filsystemet i RO og kopiere selve QCOW2-billederne, blev vi dog konfronteret med, at XFS blev dårlig af dette, og ikke umiddelbart, men på en uforudsigelig måde. Vi kan virkelig ikke lide det, når hypervisor-værter pludselig "stikker" i weekender, om natten eller på helligdage på grund af fejl, der ikke er klart, hvornår de vil ske. Derfor bruger vi ikke snapshot-montering til XFS RO for at udtrække volumener kopierer vi blot hele LVM2-volumen.

Hastigheden af ​​backup til backup-serveren bestemmes i vores tilfælde af backup-serverens ydeevne, som er omkring 600-800 MB/s for inkomprimerbare data; en yderligere begrænser er 10Gbit/s-kanalen, som backup-serveren er forbundet med til klyngen.

I dette tilfælde uploades sikkerhedskopier af 8 hypervisorservere samtidigt til én backupserver. Disk- og netværksundersystemerne på backupserveren, der er langsommere, tillader således ikke hypervisor-værternes diskundersystemer at overbelaste, da de simpelthen ikke er i stand til at behandle f.eks. 8 GB/sek., hvilket hypervisor-værterne nemt kan fremstille.

Ovenstående kopieringsproces er meget vigtig for den videre historie, inklusive detaljerne - ved at bruge et hurtigt Intel P4500-drev, ved at bruge NFS og sandsynligvis ved at bruge ZFS.

Backup historie

På hver hypervisor-node har vi en lille SWAP-partition på 8 GB i størrelse, og vi "ruller ud" selve hypervisor-noden vha. DD fra referencebilledet. Til systemvolumen på servere bruger vi 2xSATA SSD RAID1 eller 2xSAS HDD RAID1 på en LSI- eller HP-hardwarecontroller. Generelt er vi overhovedet ligeglade med, hvad der er indeni, da vores systemvolumen fungerer i "næsten skrivebeskyttet"-tilstand, bortset fra SWAP. Og da vi har meget RAM på serveren, og det er 30-40% gratis, tænker vi ikke på SWAP.

Backup proces. Denne opgave ser nogenlunde sådan ud:

#!/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

Vær opmærksom på ionice -c3, faktisk er denne ting fuldstændig ubrugelig for NVMe-enheder, da IO-planlæggeren for dem er indstillet som:

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

Vi har dog en række ældre noder med konventionelle SSD RAID'er, for dem er dette relevant, så de flytter SOM DET ER. Samlet set er dette blot et interessant stykke kode, der forklarer nytteløsheden ionice i tilfælde af en sådan konfiguration.

Vær opmærksom på flaget iflag=direct for DD. Vi bruger direkte IO-omgåelse af buffercachen for at undgå unødvendig udskiftning af IO-buffere ved læsning. Imidlertid, oflag=direct det gør vi ikke, fordi vi har stødt på ZFS-ydeevneproblemer, når vi brugte det.

Vi har brugt denne ordning med succes i flere år uden problemer.

Og så begyndte det... Vi opdagede, at en af ​​noderne ikke længere var sikkerhedskopieret, og den forrige kørte med et monstrøst IOWAIT på 50%. Da vi forsøgte at forstå, hvorfor kopiering ikke finder sted, stødte vi på følgende fænomen:

Volume group "images" not found

Vi begyndte at tænke på "enden er kommet for Intel P4500", men før du slukkede for serveren for at erstatte drevet, var det stadig nødvendigt at udføre en sikkerhedskopi. Vi rettede LVM2 ved at gendanne metadata fra en LVM2 backup:

vgcfgrestore images

Vi lancerede en backup og så dette oliemaleri:

Igen var vi meget kede af det - det var tydeligt, at vi ikke kunne leve sådan her, da alle VPS'erne ville lide, hvilket betyder, at vi også ville lide. Hvad der skete er fuldstændig uklart - iostat viste ynkelige IOPS og den højeste IOWAIT. Der var ingen andre ideer end "lad os erstatte NVMe", men en indsigt opstod lige i tide.

Analyse af situationen trin for trin

Historisk blad. Et par dage tidligere var det på denne server nødvendigt at lave en stor VPS med 128 GB RAM. Der så ud til at være hukommelse nok, men for at være på den sikre side afsatte vi yderligere 32 GB til swap-partitionen. VPS'en blev oprettet, fuldførte sin opgave med succes, og hændelsen blev glemt, men SWAP-partitionen forblev.

Konfigurationsfunktioner. For alle cloud-servere er parameteren vm.swappiness blev sat til standard 60. Og SWAP blev oprettet på SAS HDD RAID1.

Hvad skete der (ifølge redaktionen). Ved sikkerhedskopiering DD produceret en masse skrivedata, som blev placeret i RAM-buffere før skrivning til NFS. Systemkerne, styret af politik swappiness, flyttede mange sider af VPS-hukommelse til swap-området, som var placeret på en langsom HDD RAID1-diskenhed. Dette førte til, at IOWAIT voksede meget kraftigt, men ikke på grund af IO NVMe, men på grund af IO HDD RAID1.

Hvordan problemet blev løst. Swap-partitionen på 32 GB blev deaktiveret. Dette tog 16 timer; du kan læse separat om, hvordan og hvorfor SWAP slukker så langsomt. Indstillingerne er blevet ændret swappiness til en værdi lig med 5 over hele skyen.

Hvordan kunne dette ikke ske?. For det første, hvis SWAP var på en SSD RAID eller NVMe-enhed, og for det andet, hvis der ikke var nogen NVMe-enhed, men en langsommere enhed, der ikke ville producere en sådan mængde data - ironisk nok skete problemet, fordi den NVMe er for hurtig.

Derefter begyndte alt at fungere som før - med nul IOWAIT.

Kilde: www.habr.com