I denna artikel kommer jag att berĂ€tta om en situation som nyligen intrĂ€ffade med en av servrarna i vĂ„r VPS-molnlösning, vilket lĂ€mnade mig förvirrad i flera timmar. Jag har hĂ„llit pĂ„ med konfiguration och felsökning av Linux-servrar i cirka 15 Ă„r, men detta fall passar överhuvudtaget inte in i min erfarenhet â jag gjorde flera felaktiga antaganden och kĂ€nde mig lite desperat innan jag kunde identifiera orsaken till problemet och lösa det.
Inledning
Vi driver ett medelstort moln som vi bygger pĂ„ standardservrar med följande konfiguration â 32 kĂ€rnor, 256 GB RAM och en NVMe-disk av typen PCI-E Intel P4500 pĂ„ 4TB. Vi Ă€lskar verkligen denna konfiguration eftersom den lĂ„ter oss slippa tĂ€nka pĂ„ bristande IO, samtidigt som den ger en korrekt begrĂ€nsning pĂ„ instansnivĂ„ (VM-instanser). Eftersom NVMe Intel har imponerande prestanda, kan vi samtidigt garantera bĂ„de fullstĂ€ndigt IOPS-tillhandahĂ„llande till maskiner och sĂ€kerhetskopiering av lagring till en backupsserver med noll IOWAIT.
Vi tillhör de gamla typen av anvÀndare som inte anvÀnder hyperkonvergerande SDN och andra stiliga, trendiga saker för att lagra VM-volymer; vi anser att ju enklare systemet Àr, desto enklare Àr det att felsöka under "den stora gurun har Äkt bort till fjÀllen". Resultatet Àr att vi lagrar VM-volymer i QCOW2-format i XFS eller EXT4, som Àr installerat ovanpÄ LVM2.
Att anvĂ€nda QCOW2 tvingar oss ocksĂ„ pĂ„ grund av produkten som vi anvĂ€nder för orkestrering â Apache CloudStack.
För att göra sĂ€kerhetskopior tar vi ett fullstĂ€ndigt avbild av volymen, som en LVM2-snapshot (ja, vi vet att LVM2-snapshots Ă€r lĂ„ngsamma, men Intel P4500 rĂ€ddar oss Ă€ven hĂ€r). Vi gör lvmcreate -s .. och med hjĂ€lp av dd skickar vi sĂ€kerhetskopian till en fjĂ€rrserver med ZFS-lagring. HĂ€r Ă€r vi Ă€ndĂ„ lite progressiva â ZFS kan lagra data i komprimerad form, och vi kan snabbt Ă„terstĂ€lla dem med hjĂ€lp av DD eller hĂ€mta enskilda VM-volymer med hjĂ€lp av mount -o loop ....
SjÀlvklart kan man ocksÄ ta och inte ta en fullstÀndig avbild av LVM2-volymen, utan montera filsystemet i lÀge
ROoch kopiera sjÀlva QCOW2-bilderna, men vi har stött pÄ att XFS blev problematiskt av detta, och det hÀnde inte direkt utan oförutsÀgbart. Vi gillar verkligen inte nÀr hypervisorerna "lÄser sig" plötsligt pÄ helger, nÀtter eller högtider pÄ grund av fel som kan intrÀffa nÀr som helst. DÀrför anvÀnder vi inte snapshots-montering i lÀget för XFS,ROför att extrahera volymer, utan vi kopierar helt enkelt hela LVM2-volymen.
Hastigheten för sÀkerhetskopiering pÄ backup-servern bestÀms i vÄrt fall av prestandan hos backupsystemet, vilket ligger pÄ cirka 600-800 MB/s för okomprimerade data, den ytterligare begrÀnsningen Àr 10Gbit/s-kanalen som kopplar backup-servern till klustret.
Samtidigt laddar 8 servrar hypervisorer sÀkerhetskopior till en backup-server. PÄ sÄ sÀtt ger den disk- och nÀtverksinfrastruktur som backup-servern har, som Àr lÄngsammare, inte överbelasta diskunderstÀllningarna hos hypervisorerna, eftersom de helt enkelt inte kan hantera till exempel 8 GB/s, som hypervisorerna lÀtt kan leverera.
Processen för att kopiera som beskrivits ovan Àr mycket viktig för den fortsatta berÀttelsen, inklusive detaljerna - anvÀndningen av snabb lagring Intel P4500, anvÀndningen av NFS och troligen anvÀndningen av ZFS.
Historien om sÀkerhetskopiering
PÄ varje hypervisor-nod har vi en liten SWAP-partition pÄ 8 GB, och sjÀlva hypervisor-noden "rullas ut" med hjÀlp av DD en referensbild. För systemvolymen pÄ servrar anvÀnder vi 2xSATA SSD RAID1 eller 2xSAS HDD RAID1 pÄ hÄrdvarukontroller LSI eller HP. I stort sett bryr vi oss inte om vad som finns dÀr inne, eftersom systemvolymen fungerar i "nÀstan readonly"-lÀge, med undantag för SWAP. Och eftersom vi har gott om RAM pÄ servern och 30-40% Àr ledig, tÀnker vi inte pÄ SWAP.
Processen för att skapa sÀkerhetskopior. Denna uppgift ser ungefÀr ut 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-snapObservera ionice -c3, i sjÀlva verket Àr denna grej helt meningslös för NVMe-enheter, eftersom IO-schemat för dem Àr instÀllt pÄ:
cat /sys/block/nvme0n1/queue/scheduler
[none] Men vi har ett antal legacy-noder med vanliga SSD RAID, för dem Ă€r detta relevant, och dĂ€rför flyttas SOM DET ĂR. SĂ„ i stort sett Ă€r det bara en intressant bit kod som förklarar meningslösheten hos ionice i fallet med en sĂ„dan konfiguration.
Observera flaggan iflag=direct för DDVi anvÀnder direkt IO utan buffertcache för att undvika onödiga ersÀttningar av IO-buffrar vid lÀsning. Men, oflag=direct vi gör inte det, eftersom vi har stött pÄ prestandaproblem med ZFS nÀr vi anvÀnt det.
Denna metod har vi framgÄngsrikt anvÀnt i flera Är utan problem.
Och hÀr började det⊠Vi upptÀckte att sÀkerhetskopieringen för en av noderna slutade fungera, och den föregÄende körningen genomfördes med monstruös IOWAIT pÄ upp till 50%. NÀr vi försökte förstÄ varför sÀkerhetskopieringen inte genomfördes stötte vi pÄ fenomenet:
Volymgruppen "images" hittades inteVi började tÀnka pÄ "slutet har kommit för Intel P4500", men innan vi stÀngde av servern för att byta ut lagringsenheten var vi tvungna att sÀkerhetskopiera. Vi reparerade LVM2 med hjÀlp av ÄterstÀllning av metadata frÄn LVM2-backupen:
vgcfgrestore imagesVi startade sÀkerhetskopieringen och sÄg följande bild:
Vi blev Ă„terigen mycket nedstĂ€mda â det var klart att vi inte kunde fortsĂ€tta sĂ„ hĂ€r, eftersom alla VPS:er skulle drabbas, och det innebar att vi ocksĂ„ skulle lida. Vad som hĂ€nde var helt oklart â iostat visade usla IOPS och extremt hög IOWAIT. Det fanns inga andra idĂ©er Ă€n "lĂ„t oss byta ut NVMe", men plötsligt kom jag pĂ„ nĂ„got.
Analys av situationen steg för steg
Historiklogg. NÄgra dagar tidigare behövde vi skapa en stor VPS med 128 GB RAM pÄ denna server. Det verkade som om minnet var tillrÀckligt, men för att vara pÄ den sÀkra sidan tilldelades ytterligare 32 GB för swap-partitionen. VPS skapades, löste sitt problem och hÀndelsen glömdes bort, men SWAP-partitionen blev kvar.
Konfigurationsstatus. För alla servrar i molnet stÀlldes parametrarna vm.swappiness in pÄ standardvÀrdet 60. Och SWAP skapades pÄ SAS HDD RAID1.
Vad som hÀnde (enligt redaktionen). Vid sÀkerhetskopiering DD sÄg vi mÄnga skrivdata som hamnade i RAM-buffrarna innan de skrevs till NFS. Systemets kÀrna, ledd av policyn swappiness, flyttade mÄnga minnessidor frÄn VPS till swapomrÄdet som lÄg pÄ den lÄngsamma HDD RAID1-volymen. Detta ledde till en kraftig ökning av IOWAIT, men inte pÄ grund av IO frÄn NVMe, utan pÄ grund av IO frÄn HDD RAID1.
Hur problemet löstes. Swap-partitionen pÄ 32 GB stÀngdes av. Det tog 16 timmar, och hur och varför SWAP stÀngs av sÄ lÄngsamt kan lÀsas separat. Parametrarna swappiness Àndrades till vÀrdet 5 i hela molnet.
Hur kunde detta hĂ€ndaFör det första, om SWAP hade varit pĂ„ en SSD RAID eller NVMe-enhet, och för det andra, om det inte hade funnits nĂ„gon NVMe-enhet utan en lĂ„ngsammare enhet som inte kunde hantera en sĂ„dan datamĂ€ngd â ironiskt nog berodde problemet pĂ„ att NVMe var för snabbt.
Efter detta fungerade allt som tidigare â med noll IOWAIT.
KĂ€lla: habr.com
