Mye ledig RAM, NVMe Intel P4500 og alt er ekstremt tregt - historien om det mislykkede tillegget av en byttepartisjon

I denne artikkelen vil jeg snakke om en situasjon som nylig oppsto med en av serverne i VPS-skyen vår, som gjorde at jeg ble stum i flere timer. Jeg har konfigurert og feilsøkt Linux-servere i omtrent 15 år, men denne saken passer ikke inn i min praksis i det hele tatt - jeg gjorde flere falske antagelser og ble litt desperat før jeg klarte å fastslå årsaken til problemet og løse det. .

innledning

Vi driver en mellomstor sky, som vi bygger på standardservere med følgende konfigurasjon - 32 kjerner, 256 GB RAM og en 4500TB PCI-E Intel P4 NVMe-stasjon. Vi liker denne konfigurasjonen virkelig fordi den eliminerer behovet for å bekymre deg for IO-overhead ved å gi den riktige begrensningen på VM-forekomsttypenivå. Fordi NVMe Intel P4500 har imponerende ytelse, kan vi samtidig gi både full IOPS-forsyning til maskiner og backup-lagring til en backup-server med null IOWAIT.

Vi er en av de gamle troende som ikke bruker hyperkonvergert SDN og andre stilige, fasjonable ungdomsting for å lagre VM-volumer, og tror at jo enklere systemet er, desto lettere er det å feilsøke det under forholdene til "hovedguruen har gått" til fjellene." Som et resultat lagrer vi VM-volumer i QCOW2-format i XFS eller EXT4, som er distribuert på toppen av LVM2.

Vi er også tvunget til å bruke QCOW2 av produktet vi bruker til orkestrering - Apache CloudStack.

For å utføre en sikkerhetskopi tar vi et fullstendig bilde av volumet som et LVM2-øyeblikksbilde (ja, vi vet at LVM2-øyeblikksbilder er trege, men Intel P4500 hjelper oss også her). Vi gjør lvmcreate -s .. og med hjelp dd vi sender sikkerhetskopien til en ekstern server med ZFS-lagring. Her er vi fortsatt litt progressive - tross alt kan ZFS lagre data i komprimert form, og vi kan raskt gjenopprette dem ved hjelp av DD eller få individuelle VM-volumer ved å bruke mount -o loop ....

Du kan selvfølgelig ikke fjerne hele bildet av LVM2-volumet, men montere filsystemet i RO og kopiere selve QCOW2-bildene, men vi ble møtt med det faktum at XFS ble dårlig av dette, og ikke umiddelbart, men på en uforutsigbar måte. Vi liker virkelig ikke det når hypervisorverter "stikker" plutselig i helger, om natten eller på helligdager på grunn av feil som ikke er klart når de vil skje. Derfor bruker vi ikke snapshot-montering for XFS RO for å trekke ut volumer, kopierer vi ganske enkelt hele LVM2-volumet.

Hastigheten for sikkerhetskopiering til backupserveren bestemmes i vårt tilfelle av ytelsen til backupserveren, som er omtrent 600-800 MB/s for inkomprimerbare data; en ytterligere begrenser er 10Gbit/s-kanalen som backupserveren er koblet til til klyngen.

I dette tilfellet blir sikkerhetskopier av 8 hypervisorservere lastet opp samtidig til én backupserver. Disk- og nettverksundersystemene til backupserveren, som er tregere, tillater derfor ikke diskundersystemene til hypervisorvertene å overbelaste, siden de rett og slett ikke er i stand til å behandle, for eksempel, 8 GB/sek, som hypervisorvertene enkelt kan produsere.

Kopieringsprosessen ovenfor er veldig viktig for den videre historien, inkludert detaljene - ved å bruke en rask Intel P4500-stasjon, bruke NFS og sannsynligvis ZFS.

Backup historie

På hver hypervisornode har vi en liten SWAP-partisjon på 8 GB, og vi «ruller ut» selve hypervisornoden ved hjelp av DD fra referansebildet. For systemvolumet på servere bruker vi 2xSATA SSD RAID1 eller 2xSAS HDD RAID1 på en LSI- eller HP-maskinvarekontroller. Generelt bryr vi oss ikke i det hele tatt om hva som er inni, siden systemvolumet vårt fungerer i "nesten skrivebeskyttet"-modus, bortsett fra SWAP. Og siden vi har mye RAM på serveren og den er 30-40% gratis, tenker vi ikke på SWAP.

Sikkerhetskopieringsprosess. Denne oppgaven ser omtrent slik ut:

#!/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 oppmerksom på ionice -c3, faktisk er denne tingen helt ubrukelig for NVMe-enheter, siden IO-planleggeren for dem er satt som:

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

Imidlertid har vi en rekke eldre noder med konvensjonelle SSD RAIDer, for dem er dette relevant, så de flytter SOM DEN ER. Totalt sett er dette bare et interessant stykke kode som forklarer nytteløsheten ionice i tilfelle en slik konfigurasjon.

Vær oppmerksom på flagget iflag=direct for DD. Vi bruker direkte IO-omgå buffer-cachen for å unngå unødvendig utskifting av IO-buffere ved lesing. Derimot, oflag=direct vi ikke fordi vi har støtt på ZFS-ytelsesproblemer når vi bruker den.

Vi har brukt denne ordningen med suksess i flere år uten problemer.

Og så begynte det... Vi oppdaget at en av nodene ikke lenger var sikkerhetskopiert, og den forrige kjørte med en monstrøs IOWAIT på 50 %. Da vi prøvde å forstå hvorfor kopiering ikke skjer, møtte vi følgende fenomen:

Volume group "images" not found

Vi begynte å tenke på "enden har kommet for Intel P4500", men før du slo av serveren for å erstatte stasjonen, var det fortsatt nødvendig å ta en sikkerhetskopi. Vi fikset LVM2 ved å gjenopprette metadata fra en LVM2-sikkerhetskopi:

vgcfgrestore images

Vi lanserte en backup og så dette oljemaleriet:

Igjen var vi veldig triste - det var tydelig at vi ikke kunne leve slik, siden alle VPS-ene ville lide, noe som betyr at vi også ville lide. Hva som skjedde er helt uklart - iostat viste ynkelig IOPS og den høyeste IOWAIT. Det var ingen andre ideer enn "la oss erstatte NVMe", men en innsikt kom akkurat i tide.

Analyse av situasjonen trinn for trinn

Historisk magasin. Noen dager tidligere, på denne serveren, var det nødvendig å lage en stor VPS med 128 GB RAM. Det så ut til å være nok minne, men for å være på den sikre siden tildelte vi ytterligere 32 GB til byttepartisjonen. VPS-en ble opprettet, fullførte oppgaven sin og hendelsen ble glemt, men SWAP-partisjonen forble.

Konfigurasjonsfunksjoner. For alle skyservere er parameteren vm.swappiness ble satt til standard 60. Og SWAP ble opprettet på SAS HDD RAID1.

Hva skjedde (ifølge redaksjonen). Ved sikkerhetskopiering DD produserte mye skrivedata, som ble plassert i RAM-buffere før skriving til NFS. Systemkjerne, styrt av policy swappiness, flyttet mange sider med VPS-minne til bytteområdet, som var plassert på et tregt HDD RAID1-volum. Dette førte til at IOWAIT vokste veldig sterkt, men ikke på grunn av IO NVMe, men på grunn av IO HDD RAID1.

Hvordan problemet ble løst. Byttepartisjonen på 32 GB ble deaktivert. Dette tok 16 timer; du kan lese separat om hvordan og hvorfor SWAP slås av så sakte. Innstillingene er endret swappiness til en verdi lik 5 over hele skyen.

Hvordan kunne dette ikke skje?. For det første, hvis SWAP var på en SSD RAID eller NVMe-enhet, og for det andre, hvis det ikke var noen NVMe-enhet, men en tregere enhet som ikke ville produsere et slikt datavolum - ironisk nok skjedde problemet fordi den NVMe er for rask.

Etter det begynte alt å fungere som før - med null IOWAIT.

Kilde: www.habr.com