In hierdie artikel sal ek praat oor 'n situasie wat onlangs plaasgevind het met een van die bedieners in ons VPS-wolk, wat my 'n paar uur lank stomgeslaan het. Ek konfigureer en oplos al vir ongeveer 15 jaar Linux-bedieners, maar hierdie geval pas glad nie by my praktyk in nie - ek het verskeie valse aannames gemaak en het 'n bietjie desperaat geraak voordat ek die oorsaak van die probleem korrek kon bepaal en dit kon oplos .
aanhef
Ons bedryf 'n mediumgrootte wolk, wat ons bou op standaardbedieners met die volgende konfigurasie - 32 kerns, 256 GB RAM en 'n 4500TB PCI-E Intel P4 NVMe-aandrywer. Ons hou baie van hierdie konfigurasie, want dit elimineer die behoefte om bekommerd te wees oor IO-bokoste deur die korrekte beperking op die VM-instansievlak te verskaf. Omdat NVMe Intel indrukwekkende werkverrigting het, kan ons gelyktydig beide volledige IOPS-voorsiening aan masjiene en rugsteunberging aan 'n rugsteunbediener met nul IOWAIT verskaf.
Ons is een van daardie ou gelowiges wat nie hipergekonvergeerde SDN en ander stylvolle, modieuse jeugdinge gebruik om VM-volumes te stoor nie, en glo dat hoe eenvoudiger die stelsel is, hoe makliker is dit om dit op te los in die toestande van "die hoofghoeroe is weg. na die berge.” As gevolg hiervan berg ons VM-volumes in QCOW2-formaat in XFS of EXT4, wat bo-op LVM2 ontplooi word.
Ons word ook gedwing om QCOW2 te gebruik deur die produk wat ons vir orkestrasie gebruik - Apache CloudStack.
Om 'n rugsteun uit te voer, neem ons 'n volledige beeld van die volume as 'n LVM2-kiekie (ja, ons weet dat LVM2-kiekies stadig is, maar die Intel P4500 help ons ook hier). Ons doen lvmcreate -s .. en met die hulp dd ons stuur die rugsteunkopie na 'n afgeleë bediener met ZFS-berging. Hier is ons steeds effens progressief - ZFS kan immers data in saamgeperste vorm stoor, en ons kan dit vinnig herstel met DD of kry individuele VM-volumes met behulp van mount -o loop ....
U kan natuurlik nie die volle beeld van die LVM2-volume verwyder nie, maar die lêerstelsel in die
ROen kopieer die QCOW2-beelde self, maar ons het gekonfronteer met die feit dat XFS hierdeur sleg geword het, en nie dadelik nie, maar op 'n onvoorspelbare manier. Ons hou regtig nie daarvan as hypervisor-gashere skielik oor naweke, snags of vakansiedae "plak" as gevolg van foute wat nie duidelik is wanneer dit sal gebeur nie. Daarom, vir XFS gebruik ons nie momentopname-montering in nieROom volumes te onttrek, kopieer ons eenvoudig die hele LVM2-volume.
Die spoed van rugsteun na die rugsteunbediener word in ons geval bepaal deur die werkverrigting van die rugsteunbediener, wat ongeveer 600-800 MB/s is vir onsamedrukbare data; 'n verdere beperker is die 10Gbit/s-kanaal waarmee die rugsteunbediener gekoppel is na die cluster.
In hierdie geval word rugsteunkopieë van 8 hypervisor-bedieners gelyktydig na een rugsteunbediener opgelaai. Dus, die skyf- en netwerksubstelsels van die rugsteunbediener, wat stadiger is, laat nie toe dat die skyfsubstelsels van die hypervisor-gashere oorlaai nie, aangesien hulle eenvoudig nie in staat is om byvoorbeeld 8 GB/sek te verwerk nie, wat die hipervisor-gashere maklik kan produseer.
Die bogenoemde kopieerproses is baie belangrik vir die verdere storie, insluitend die besonderhede - die gebruik van 'n vinnige Intel P4500-aandrywer, die gebruik van NFS en, waarskynlik, die gebruik van ZFS.
Rugsteun storie
Op elke hipervisor-nodus het ons 'n klein SWAP-partisie van 8 GB groot, en ons "rol" die hipervisor-nodus self met DD vanaf die verwysingsbeeld. Vir die stelselvolume op bedieners gebruik ons 2xSATA SSD RAID1 of 2xSAS HDD RAID1 op 'n LSI of HP hardeware kontroleerder. Oor die algemeen gee ons glad nie om wat binne is nie, aangesien ons stelselvolume in "amper leesalleen"-modus werk, behalwe vir SWAP. En aangesien ons baie RAM op die bediener het en dit 30-40% gratis is, dink ons nie aan SWAP nie.
Rugsteun proses. Hierdie taak lyk so iets:
#!/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-snapgee aandag aan ionice -c3Trouens, hierdie ding is heeltemal nutteloos vir NVMe-toestelle, aangesien die IO-skeduleerder vir hulle ingestel is as:
cat /sys/block/nvme0n1/queue/scheduler
[none] Ons het egter 'n aantal verouderde nodusse met konvensionele SSD RAID's, vir hulle is dit relevant, so hulle beweeg NETSO. Oor die algemeen is dit net 'n interessante stukkie kode wat die nutteloosheid verduidelik ionice in die geval van so 'n konfigurasie.
Gee aandag aan die vlag iflag=direct vir DD. Ons gebruik direkte IO om die bufferkas te omseil om onnodige vervanging van IO-buffers tydens lees te vermy. Maar oflag=direct ons doen dit nie, want ons het ZFS-prestasieprobleme ondervind wanneer ons dit gebruik.
Ons gebruik hierdie skema al vir etlike jare sonder probleme suksesvol.
En toe begin dit... Ons het ontdek dat een van die nodusse nie meer gerugsteun is nie, en die vorige een het met 'n monsteragtige IOWAIT van 50% geloop. Toe ons probeer verstaan waarom kopiëring nie plaasvind nie, het ons die volgende verskynsel teëgekom:
Volume group "images" not foundOns het begin dink aan "die einde het gekom vir die Intel P4500," maar voordat ons die bediener afgeskakel het om die aandrywer te vervang, was dit steeds nodig om 'n rugsteun uit te voer. Ons het LVM2 reggemaak deur metadata vanaf 'n LVM2-rugsteun te herstel:
vgcfgrestore imagesOns het 'n rugsteun geloods en hierdie olieverfskildery gesien:
Weereens was ons baie hartseer - dit was duidelik dat ons nie so kon lewe nie, aangesien al die VPS'e sou ly, wat beteken dat ons ook sou ly. Wat gebeur het is heeltemal onduidelik - iostat het jammerlike IOPS en die hoogste IOWAIT getoon. Daar was geen ander idees as "kom ons vervang NVMe", maar 'n insig het net betyds plaasgevind.
Ontleding van die situasie stap vir stap
Historiese tydskrif. 'n Paar dae vroeër was dit op hierdie bediener nodig om 'n groot VPS met 128 GB RAM te skep. Dit het gelyk of daar genoeg geheue was, maar om aan die veilige kant te wees, het ons nog 32 GB vir die ruilpartisie toegewys. Die VPS is geskep, het sy taak suksesvol voltooi en die voorval is vergeet, maar die SWAP-partisie het gebly.
Konfigurasiekenmerke. Vir alle wolkbedieners is die parameter vm.swappiness is op verstek gestel 60. En SWAP is geskep op SAS HDD RAID1.
Wat het gebeur (volgens die redaksie). Wanneer u rugsteun DD het baie skryfdata geproduseer, wat in RAM-buffers geplaas is voordat dit na NFS geskryf is. Stelselkern, gelei deur beleid swappiness, was besig om baie bladsye VPS-geheue na die ruilarea te verskuif, wat op 'n stadige HDD RAID1-volume geleë was. Dit het daartoe gelei dat IOWAIT baie sterk gegroei het, maar nie as gevolg van IO NVMe nie, maar as gevolg van IO HDD RAID1.
Hoe die probleem opgelos is. Die 32GB-omruilpartisie is gedeaktiveer. Dit het 16 uur geneem; jy kan afsonderlik lees oor hoe en hoekom SWAP so stadig afskakel. Instellings is verander swappiness tot 'n waarde gelyk aan 5 oor die hele wolk.
Hoe kon dit nie gebeur nie?. Eerstens, as SWAP op 'n SSD RAID of NVMe toestel was, en tweedens, as daar geen NVMe toestel was nie, maar 'n stadiger toestel wat nie so 'n volume data sou produseer nie - ironies genoeg het die probleem gebeur omdat daardie NVMe te vinnig is.
Daarna het alles begin werk soos voorheen – met nul IOWAIT.
Bron: will.com