Veel gratis RAM, NVMe Intel P4500 en alles is extreem traag - het verhaal van de mislukte toevoeging van een swappartitie

In dit artikel zal ik het hebben over een situatie die zich onlangs heeft voorgedaan met een van de servers in onze VPS-cloud, waardoor ik enkele uren met stomheid geslagen was. Ik ben al ongeveer 15 jaar bezig met het configureren en oplossen van problemen met Linux-servers, maar dit geval past helemaal niet in mijn praktijk - ik maakte verschillende valse aannames en werd een beetje wanhopig voordat ik de oorzaak van het probleem correct kon vaststellen en oplossen .

Преамбула

We exploiteren een middelgrote cloud, die we bouwen op standaardservers met de volgende configuratie: 32 cores, 256 GB RAM en een 4500TB PCI-E Intel P4 NVMe-schijf. We zijn erg blij met deze configuratie omdat het de noodzaak elimineert om ons zorgen te maken over IO-overhead door de juiste beperking op het niveau van het VM-instantietype te bieden. Omdat NVMe Intel P4500 indrukwekkende prestaties levert, kunnen we tegelijkertijd zowel volledige IOPS-provisioning voor machines als back-upopslag op een back-upserver zonder IOWAIT leveren.

Wij zijn een van die oude gelovigen die geen hypergeconvergeerde SDN en andere stijlvolle, modieuze, jeugdige dingen gebruiken om VM-volumes op te slaan, in de overtuiging dat hoe eenvoudiger het systeem, hoe gemakkelijker het is om problemen op te lossen in de omstandigheden van ‘de hoofdgoeroe is verdwenen’. naar de bergen." Als gevolg hiervan slaan we VM-volumes op in QCOW2-formaat in XFS of EXT4, dat bovenop LVM2 wordt geïmplementeerd.

We zijn ook gedwongen om QCOW2 te gebruiken door het product dat we gebruiken voor orkestratie: Apache CloudStack.

Om een ​​back-up uit te voeren, maken we een volledige afbeelding van het volume als een LVM2-snapshot (ja, we weten dat LVM2-snapshots traag zijn, maar de Intel P4500 helpt ons hier ook mee). Wij doen lvmcreate -s .. en met de hulp dd we sturen de back-up naar een externe server met ZFS-opslag. Hier zijn we nog steeds enigszins vooruitstrevend: ZFS kan gegevens immers in gecomprimeerde vorm opslaan en we kunnen deze snel herstellen met behulp van DD of download individuele VM-volumes met behulp van mount -o loop ....

U kunt uiteraard niet de volledige afbeelding van het LVM2-volume verwijderen, maar het bestandssysteem in het RO en de QCOW2-afbeeldingen zelf kopiëren, werden we echter geconfronteerd met het feit dat XFS hierdoor slecht werd, en niet onmiddellijk, maar op een onvoorspelbare manier. We houden er echt niet van als hypervisor-hosts in het weekend, 's nachts of op feestdagen plotseling blijven hangen vanwege fouten waarvan niet duidelijk is wanneer ze zullen gebeuren. Daarom gebruiken we voor XFS geen snapshot-montage RO om volumes te extraheren, kopiëren we eenvoudigweg het volledige LVM2-volume.

De snelheid van de back-up naar de back-upserver wordt in ons geval bepaald door de prestaties van de back-upserver, die voor incomprimeerbare data ongeveer 600-800 MB/s bedraagt; een verdere begrenzer is het 10Gbit/s-kanaal waarmee de back-upserver is verbonden naar het cluster.

In dit geval worden back-upkopieën van 8 hypervisorservers gelijktijdig geüpload naar één back-upserver. Omdat de schijf- en netwerksubsystemen van de back-upserver langzamer zijn, kunnen de schijfsubsystemen van de hypervisor-hosts dus niet overbelast raken, omdat ze eenvoudigweg niet in staat zijn om bijvoorbeeld 8 GB/sec te verwerken, wat de hypervisor-hosts gemakkelijk kunnen verwerken. produceren.

Het bovenstaande kopieerproces is erg belangrijk voor het verdere verhaal, inclusief de details: het gebruik van een snelle Intel P4500-schijf, het gebruik van NFS en waarschijnlijk het gebruik van ZFS.

Back-upverhaal

Op elk hypervisorknooppunt hebben we een kleine SWAP-partitie van 8 GB groot, en we ‘rollen’ het hypervisorknooppunt zelf uit met behulp van DD van het referentiebeeld. Voor het systeemvolume op servers gebruiken we 2xSATA SSD RAID1 of 2xSAS HDD RAID1 op een LSI of HP hardwarecontroller. Over het algemeen maakt het ons helemaal niets uit wat erin zit, omdat ons systeemvolume in de “bijna alleen-lezen” modus werkt, behalve voor SWAP. En aangezien we veel RAM op de server hebben en het 30-40% gratis is, denken we niet aan SWAP.

Back-upproces. Deze taak ziet er ongeveer zo uit:

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

Besteed aandacht aan ionice -c3In feite is dit ding volkomen nutteloos voor NVMe-apparaten, omdat de IO-planner ervoor is ingesteld als:

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

We hebben echter een aantal oudere knooppunten met conventionele SSD RAID's, voor hen is dit relevant, dus ze verhuizen ZOALS HET IS. Over het algemeen is dit slechts een interessant stukje code dat de nutteloosheid verklaart ionice in het geval van een dergelijke configuratie.

Let op de vlag iflag=direct voor DD. We gebruiken directe IO waarbij de buffercache wordt omzeild om onnodige vervanging van IO-buffers tijdens het lezen te voorkomen. Echter, oflag=direct dat doen we niet omdat we prestatieproblemen met ZFS zijn tegengekomen bij het gebruik ervan.

Wij maken al enkele jaren met succes gebruik van deze regeling zonder problemen.

En toen begon het... We ontdekten dat van een van de knooppunten geen back-up meer werd gemaakt, en dat de vorige draaide met een monsterlijke IOWAIT van 50%. Toen we probeerden te begrijpen waarom kopiëren niet plaatsvindt, kwamen we het volgende fenomeen tegen:

Volume group "images" not found

We begonnen na te denken over “het einde is gekomen voor de Intel P4500”, maar voordat we de server uitschakelden om de schijf te vervangen, was het nog steeds nodig om een ​​back-up uit te voeren. We hebben LVM2 gerepareerd door metadata te herstellen vanaf een LVM2-back-up:

vgcfgrestore images

We lanceerden een back-up en zagen dit olieverfschilderij:

Opnieuw waren we erg verdrietig - het was duidelijk dat we zo niet konden leven, omdat alle VPS'en eronder zouden lijden, wat betekent dat wij ook zouden lijden. Wat er is gebeurd is volkomen onduidelijk iostat toonde zielige IOPS en de hoogste IOWAIT. Er waren geen andere ideeën dan ‘laten we NVMe vervangen’, maar een inzicht kwam net op tijd.

Analyse van de situatie stap voor stap

Historisch tijdschrift. Een paar dagen eerder was het op deze server nodig om een ​​grote VPS met 128 GB RAM te creëren. Er leek voldoende geheugen te zijn, maar voor de zekerheid hebben we nog eens 32 GB toegewezen voor de swappartitie. De VPS werd aangemaakt, voltooide zijn taak met succes en het incident werd vergeten, maar de SWAP-partitie bleef bestaan.

Configuratiefuncties. Voor alle cloudservers is de parameter vm.swappiness stond op standaard 60. En SWAP is gemaakt op SAS HDD RAID1.

Wat is er gebeurd (volgens de redactie). Bij het maken van een back-up DD produceerde veel schrijfgegevens, die in RAM-buffers werden geplaatst voordat ze naar NFS werden geschreven. Systeemkern, geleid door beleid swappiness, verplaatste veel pagina's VPS-geheugen naar het swapgebied, dat zich op een langzaam HDD RAID1-volume bevond. Dit leidde ertoe dat IOWAIT zeer sterk groeide, maar niet dankzij IO NVMe, maar dankzij IO HDD RAID1.

Hoe het probleem werd opgelost. De swappartitie van 32 GB is uitgeschakeld. Dit duurde 16 uur; hoe en waarom SWAP zo langzaam uitschakelt, kun je apart lezen. Instellingen zijn gewijzigd swappiness naar een waarde gelijk aan 5 overal in de wolk.

Hoe kon dit niet gebeuren?. Ten eerste, als SWAP zich op een SSD RAID- of NVMe-apparaat zou bevinden, en ten tweede, als er geen NVMe-apparaat was, maar een langzamer apparaat dat niet zo'n hoeveelheid gegevens zou produceren - ironisch genoeg deed het probleem zich voor omdat die NVMe te snel is.

Daarna begon alles te werken zoals voorheen - zonder IOWAIT.

Bron: www.habr.com