Mae llawer o RAM am ddim, NVMe Intel P4500 a phopeth yn hynod o araf - stori ychwanegiad aflwyddiannus rhaniad cyfnewid

Yn yr erthygl hon, byddaf yn siarad am sefyllfa a ddigwyddodd yn ddiweddar gydag un o'r gweinyddwyr yn ein cwmwl VPS, a adawodd i mi stwmpio am sawl awr. Rwyf wedi bod yn ffurfweddu ac yn datrys problemau gweinyddwyr Linux ers tua 15 mlynedd, ond nid yw'r achos hwn yn cyd-fynd â'm harfer o gwbl - gwnes sawl rhagdybiaeth ffug a chefais ychydig yn anobeithiol cyn i mi allu pennu achos y broblem yn gywir a'i datrys .

Rhagarweiniad

Rydym yn gweithredu cwmwl maint canolig, yr ydym yn adeiladu ar weinyddion safonol gyda'r ffurfweddiad canlynol - 32 cores, 256 GB RAM a gyriant 4500TB PCI-E Intel P4 NVMe. Rydyn ni'n hoff iawn o'r cyfluniad hwn oherwydd ei fod yn dileu'r angen i boeni am IO uwchben trwy ddarparu'r cyfyngiad cywir ar lefel math enghraifft VM. Oherwydd NVMe Intel P4500 â pherfformiad trawiadol, gallwn ar yr un pryd ddarparu darpariaeth IOPS lawn i beiriannau a storfa wrth gefn i weinydd wrth gefn gyda sero IOWAIT.

Rydyn ni'n un o'r hen gredinwyr hynny nad ydyn nhw'n defnyddio SDN hyperconverged a phethau ieuenctid chwaethus, ffasiynol eraill i storio cyfrolau VM, gan gredu po symlaf yw'r system, yr hawsaf yw hi i'w datrys dan amodau “mae'r prif guru wedi mynd. i'r mynyddoedd.” O ganlyniad, rydym yn storio cyfrolau VM mewn fformat QCOW2 yn XFS neu EXT4, sy'n cael ei ddefnyddio ar ben LVM2.

Rydym hefyd yn cael ein gorfodi i ddefnyddio QCOW2 gan y cynnyrch a ddefnyddiwn ar gyfer offeryniaeth - Apache CloudStack.

I berfformio copi wrth gefn, rydyn ni'n cymryd delwedd lawn o'r gyfrol fel ciplun LVM2 (ie, rydyn ni'n gwybod bod cipluniau LVM2 yn araf, ond mae'r Intel P4500 yn ein helpu ni yma hefyd). Gwnawn lvmcreate -s .. a chyda chymorth dd rydym yn anfon y copi wrth gefn i weinydd pell gyda storfa ZFS. Yma rydym yn dal i fod ychydig yn flaengar - wedi'r cyfan, gall ZFS storio data ar ffurf gywasgedig, a gallwn ei adfer yn gyflym gan ddefnyddio DD neu gael cyfeintiau VM unigol gan ddefnyddio mount -o loop ....

Gallwch, wrth gwrs, nid dileu delwedd lawn y gyfrol LVM2, ond gosod y system ffeiliau yn y RO a chopïo'r delweddau QCOW2 eu hunain, fodd bynnag, roeddem yn wynebu'r ffaith bod XFS wedi dod yn ddrwg o hyn, ac nid ar unwaith, ond mewn ffordd anrhagweladwy. Nid ydym yn ei hoffi mewn gwirionedd pan fydd hypervisor yn cynnal “ffon” yn sydyn ar benwythnosau, gyda'r nos neu ar wyliau oherwydd gwallau nad ydynt yn glir pryd y byddant yn digwydd. Felly, ar gyfer XFS nid ydym yn defnyddio gosod ciplun i mewn RO i echdynnu cyfrolau, rydym yn syml yn copïo'r gyfrol LVM2 gyfan.

Mae cyflymder gwneud copi wrth gefn i'r gweinydd wrth gefn yn cael ei bennu yn ein hachos ni gan berfformiad y gweinydd wrth gefn, sef tua 600-800 MB/s ar gyfer data anghywasgadwy; cyfyngydd pellach yw'r sianel 10Gbit yr eiliad y mae'r gweinydd wrth gefn wedi'i gysylltu â hi. i'r clwstwr.

Yn yr achos hwn, mae copïau wrth gefn o 8 gweinydd hypervisor yn cael eu huwchlwytho ar yr un pryd i un gweinydd wrth gefn. Felly, gan eu bod yn arafach, nid yw is-systemau disg a rhwydwaith y gweinydd wrth gefn yn caniatáu i is-systemau disg y gwesteiwyr hypervisor orlwytho, gan nad ydynt yn gallu prosesu, dyweder, 8 GB / eiliad, y gall yr hypervisor ei gynnal yn hawdd. cynnyrch.

Mae'r broses gopïo uchod yn bwysig iawn ar gyfer y stori bellach, gan gynnwys y manylion - gan ddefnyddio gyriant Intel P4500 cyflym, gan ddefnyddio NFS ac, yn ôl pob tebyg, defnyddio ZFS.

Stori wrth gefn

Ar bob nod hypervisor mae gennym raniad SWAP bach o 8 GB o faint, ac rydym yn “rholio” y nod hypervisor ei hun gan ddefnyddio DD o'r ddelwedd gyfeirio. Ar gyfer cyfaint y system ar weinyddion, rydym yn defnyddio 2xSATA SSD RAID1 neu 2xSAS HDD RAID1 ar reolwr caledwedd LSI neu HP. Yn gyffredinol, nid oes ots gennym o gwbl beth sydd y tu mewn, gan fod cyfaint ein system yn gweithredu yn y modd “bron yn ddarllenadwy”, ac eithrio SWAP. A chan fod gennym lawer o RAM ar y gweinydd a'i fod yn 30-40% am ddim, nid ydym yn meddwl am SWAP.

Proses gwneud copi wrth gefn. Mae'r dasg hon yn edrych fel hyn:

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

Rhowch sylw i ionice -c3, mewn gwirionedd, mae'r peth hwn yn gwbl ddiwerth ar gyfer dyfeisiau NVMe, gan fod yr amserlennydd IO ar eu cyfer wedi'i osod fel:

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

Fodd bynnag, mae gennym nifer o nodau etifeddiaeth gyda RAID SSD confensiynol, ar eu cyfer mae hyn yn berthnasol, felly maent yn symud FEL YW. At ei gilydd, dim ond darn diddorol o god yw hwn sy'n esbonio'r oferedd ionice rhag ofn y bydd cyfluniad o'r fath.

Rhowch sylw i'r faner iflag=direct gyfer DD. Rydym yn defnyddio IO uniongyrchol osgoi'r storfa byffer i osgoi disodli byfferau IO yn ddiangen wrth ddarllen. Fodd bynnag, oflag=direct nid ydym oherwydd ein bod wedi dod ar draws materion perfformiad ZFS wrth ei ddefnyddio.

Rydym wedi bod yn defnyddio'r cynllun hwn yn llwyddiannus ers sawl blwyddyn heb broblemau.

Ac yna y dechreuodd... Fe wnaethon ni ddarganfod nad oedd copi wrth gefn o un o'r nodau bellach, ac roedd yr un blaenorol yn rhedeg gydag IOWAIT gwrthun o 50%. Wrth geisio deall pam nad yw copïo yn digwydd, daethom ar draws y ffenomen ganlynol:

Volume group "images" not found

Dechreuon ni feddwl am “mae'r diwedd wedi dod ar gyfer yr Intel P4500,” fodd bynnag, cyn diffodd y gweinydd i ddisodli'r gyriant, roedd yn dal yn angenrheidiol i berfformio copi wrth gefn. Fe wnaethom drwsio LVM2 trwy adfer metadata o gopi wrth gefn LVM2:

vgcfgrestore images

Fe wnaethom lansio copi wrth gefn a gweld y paentiad olew hwn:

Unwaith eto roeddem yn drist iawn - roedd yn amlwg na allem fyw fel hyn, gan y byddai pob VPS yn dioddef, sy'n golygu y byddem yn dioddef hefyd. Mae'r hyn a ddigwyddodd yn gwbl aneglur - iostat dangosodd IOPS truenus a'r IOWAIT uchaf. Nid oedd unrhyw syniadau heblaw “gadewch i ni ddisodli NVMe,” ond digwyddodd mewnwelediad mewn pryd.

Dadansoddiad o'r sefyllfa gam wrth gam

Cylchgrawn hanesyddol. Ychydig ddyddiau ynghynt, ar y gweinydd hwn roedd angen creu VPS mawr gyda 128 GB RAM. Roedd yn ymddangos bod digon o gof, ond i fod ar yr ochr ddiogel, fe wnaethom ddyrannu 32 GB arall ar gyfer y rhaniad cyfnewid. Crëwyd y VPS, cwblhaodd ei dasg yn llwyddiannus ac anghofiwyd y digwyddiad, ond parhaodd y rhaniad SWAP.

Nodweddion Ffurfweddu. Ar gyfer pob gweinydd cwmwl y paramedr vm.swappiness ei osod yn rhagosodedig 60. A chrëwyd SWAP ar SAS HDD RAID1.

Beth ddigwyddodd (yn ôl y golygyddion). Wrth wneud copi wrth gefn DD cynhyrchu llawer o ddata ysgrifennu, a osodwyd mewn byfferau RAM cyn ysgrifennu i NFS. Craidd y system, wedi'i arwain gan bolisi swappiness, yn symud llawer o dudalennau o gof VPS i'r ardal gyfnewid, a oedd wedi'i leoli ar gyfrol HDD RAID1 araf. Arweiniodd hyn at dyfu IOWAIT yn gryf iawn, ond nid oherwydd IO NVMe, ond oherwydd IO HDD RAID1.

Sut y cafodd y broblem ei datrys. Roedd y rhaniad cyfnewid 32GB wedi'i analluogi. Cymerodd hyn 16 awr; gallwch ddarllen ar wahân sut a pham mae SWAP yn diffodd mor araf. Mae gosodiadau wedi'u newid swappiness i werth cyfartal i 5 ar hyd y cwmwl.

Sut na allai hyn ddigwydd?. Yn gyntaf, pe bai SWAP ar ddyfais SSD RAID neu NVMe, ac yn ail, os nad oedd dyfais NVMe, ond dyfais arafach na fyddai'n cynhyrchu cymaint o ddata - yn eironig, digwyddodd y broblem oherwydd bod NVMe yn rhy gyflym.

Ar ôl hynny, dechreuodd popeth weithio fel o'r blaen - gyda sero IOWAIT.

Ffynhonnell: hab.com