Mycket gratis RAM, NVMe Intel P4500 och allt är extremt långsamt - historien om det misslyckade tillägget av en swap-partition

I den här artikeln kommer jag att prata om en situation som nyligen inträffade med en av servrarna i vårt VPS-moln, vilket gjorde att jag blev stum i flera timmar. Jag har konfigurerat och felsökt Linux-servrar i cirka 15 år, men det här fallet passar inte alls in i min praxis - jag gjorde flera falska antaganden och blev lite desperat innan jag kunde korrekt fastställa orsaken till problemet och lösa det .

ingressen

Vi driver ett medelstort moln, som vi bygger på standardservrar med följande konfiguration - 32 kärnor, 256 GB RAM och en 4500TB PCI-E Intel P4 NVMe-enhet. Vi gillar verkligen den här konfigurationen eftersom den eliminerar behovet av att oroa sig för IO-overhead genom att tillhandahålla rätt begränsning på VM-instansnivå. Eftersom NVMe Intel P4500 har imponerande prestanda, kan vi samtidigt tillhandahålla både fullständig IOPS-provisionering till maskiner och backuplagring till en backupserver med noll IOWAIT.

Vi är en av de gamla troende som inte använder hyperkonvergerad SDN och andra snygga, fashionabla ungdomssaker för att lagra VM-volymer, och tror att ju enklare systemet är, desto lättare är det att felsöka det under förhållanden som ”huvudgurun har gått. till Bergen." Som ett resultat lagrar vi VM-volymer i QCOW2-format i XFS eller EXT4, som distribueras ovanpå LVM2.

Vi är också tvungna att använda QCOW2 av produkten vi använder för orkestrering - Apache CloudStack.

För att göra en säkerhetskopiering tar vi en fullständig bild av volymen som en LVM2-ögonblicksbild (ja, vi vet att LVM2-ögonblicksbilder är långsamma, men Intel P4500 hjälper oss också här). Vi gör lvmcreate -s .. och med hjälp dd vi skickar säkerhetskopian till en fjärrserver med ZFS-lagring. Här är vi fortfarande något progressiva - trots allt kan ZFS lagra data i komprimerad form, och vi kan snabbt återställa den med DD eller skaffa individuella VM-volymer med hjälp av mount -o loop ....

Du kan naturligtvis inte ta bort hela bilden av LVM2-volymen, utan montera filsystemet i RO och kopiera själva QCOW2-bilderna, men vi ställdes inför det faktum att XFS blev dålig av detta, och inte direkt, utan på ett oförutsägbart sätt. Vi gillar verkligen inte när hypervisorvärdar plötsligt "sticker" på helger, på natten eller på helgdagar på grund av fel som inte är klart när de kommer att hända. Därför använder vi inte snapshot-montering för XFS RO för att extrahera volymer kopierar vi helt enkelt hela LVM2-volymen.

Hastigheten för säkerhetskopiering till backupservern bestäms i vårt fall av backupserverns prestanda, vilket är cirka 600-800 MB/s för inkomprimerbar data; en ytterligare begränsning är 10Gbit/s-kanalen som backupservern är ansluten till till klustret.

I det här fallet laddas säkerhetskopior av 8 hypervisorservrar upp samtidigt till en backupserver. Säkerhetskopieringsserverns disk- och nätverksundersystem, eftersom de är långsammare, tillåter inte att hypervisorvärdarnas diskundersystem överbelastas, eftersom de helt enkelt inte kan bearbeta t.ex. 8 GB/sek, vilket hypervisorvärdarna lätt kan producera.

Ovanstående kopieringsprocessen är mycket viktig för den fortsatta historien, inklusive detaljerna - att använda en snabb Intel P4500-enhet, använda NFS och, förmodligen, med ZFS.

Backup berättelse

På varje hypervisornod har vi en liten SWAP-partition på 8 GB och vi "rullar ut" själva hypervisornoden med hjälp av DD från referensbilden. För systemvolymen på servrar använder vi 2xSATA SSD RAID1 eller 2xSAS HDD RAID1 på en LSI- eller HP-hårdvarukontroller. I allmänhet bryr vi oss inte alls om vad som finns inuti, eftersom vår systemvolym fungerar i "nästan skrivskyddat" läge, förutom SWAP. Och eftersom vi har mycket RAM-minne på servern och det är 30-40% gratis, tänker vi inte på SWAP.

Säkerhetskopieringsprocess. Den här uppgiften ser ut ungefär så här:

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

Var uppmärksam på ionice -c3, i själva verket är den här saken helt värdelös för NVMe-enheter, eftersom IO-schemaläggaren för dem är inställd som:

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

Vi har dock ett antal äldre noder med konventionella SSD RAID, för dem är detta relevant, så de flyttar SOM DEN ÄR. Sammantaget är detta bara en intressant kod som förklarar meningslösheten ionice vid en sådan konfiguration.

Var uppmärksam på flaggan iflag=direct för DD. Vi använder direkt IO förbikoppling av buffertcachen för att undvika onödiga utbyten av IO-buffertar vid läsning. Dock, oflag=direct det gör vi inte eftersom vi har stött på ZFS-prestandaproblem när vi använder den.

Vi har använt detta system framgångsrikt i flera år utan problem.

Och så började det... Vi upptäckte att en av noderna inte längre var säkerhetskopierad, och den föregående körde med ett monstruöst IOWAIT på 50%. När vi försökte förstå varför kopiering inte sker, stötte vi på följande fenomen:

Volume group "images" not found

Vi började fundera på "slutet har kommit för Intel P4500", men innan vi stängde av servern för att ersätta enheten var det fortfarande nödvändigt att göra en säkerhetskopia. Vi fixade LVM2 genom att återställa metadata från en LVM2-säkerhetskopia:

vgcfgrestore images

Vi startade en backup och såg den här oljemålningen:

Återigen var vi väldigt ledsna - det var tydligt att vi inte kunde leva så här, eftersom alla VPS:er skulle lida, vilket betyder att vi också skulle lida. Vad som hände är helt oklart - iostat visade ynkliga IOPS och högsta IOWAIT. Det fanns inga andra idéer än "låt oss ersätta NVMe", men en insikt kom precis i tid.

Analys av situationen steg för steg

Historisk tidskrift. Några dagar tidigare, på denna server var det nödvändigt att skapa en stor VPS med 128 GB RAM. Det verkade finnas tillräckligt med minne, men för att vara på den säkra sidan tilldelade vi ytterligare 32 GB för swap-partitionen. VPS skapades, slutförde sin uppgift framgångsrikt och incidenten glömdes, men SWAP-partitionen fanns kvar.

Konfigurationsfunktioner. För alla molnservrar parametern vm.swappiness var inställd på standard 60. Och SWAP skapades på SAS HDD RAID1.

Vad hände (enligt redaktionen). Vid säkerhetskopiering DD producerade mycket skrivdata, som placerades i RAM-buffertar innan man skrev till NFS. Systemkärna, styrd av policy swappiness, flyttade många sidor av VPS-minne till växlingsområdet, som låg på en långsam HDD RAID1-volym. Detta ledde till att IOWAIT växte väldigt starkt, men inte på grund av IO NVMe, utan på grund av IO HDD RAID1.

Hur problemet löstes. 32 GB swap-partitionen inaktiverades. Detta tog 16 timmar, du kan läsa separat om hur och varför SWAP stängs av så långsamt. Inställningarna har ändrats swappiness till ett värde lika med 5 över hela molnet.

Hur kunde detta inte hända?. För det första, om SWAP var på en SSD RAID eller NVMe-enhet, och för det andra, om det inte fanns någon NVMe-enhet, utan en långsammare enhet som inte skulle producera en sådan mängd data - ironiskt nog inträffade problemet eftersom den NVMe är för snabb.

Efter det började allt fungera som förut – med noll IOWAIT.

Källa: will.com