RAM nyingi za bure, NVMe Intel P4500 na kila kitu ni polepole sana - hadithi ya uongezaji usiofanikiwa wa kizigeu cha kubadilishana.

Katika nakala hii, nitazungumza juu ya hali ambayo ilitokea hivi karibuni na seva moja kwenye wingu letu la VPS, ambayo iliniacha nikiwa na mshangao kwa masaa kadhaa. Nimekuwa nikisanidi na kusuluhisha seva za Linux kwa takriban miaka 15, lakini kesi hii haiendani na mazoezi yangu hata kidogo - nilifanya mawazo kadhaa ya uwongo na nikakata tamaa kidogo kabla ya kuweza kuamua kwa usahihi sababu ya shida na kuisuluhisha. .

Kuelezea

Tunatumia wingu la ukubwa wa kati, ambalo tunaunda kwenye seva za kawaida na usanidi ufuatao - cores 32, RAM ya GB 256 na kiendeshi cha 4500TB PCI-E Intel P4 NVMe. Tunapenda sana usanidi huu kwa sababu huondoa hitaji la kuwa na wasiwasi kuhusu IO kwa kutoa kizuizi sahihi katika kiwango cha aina ya mfano wa VM. Kwa sababu NVMe Intel P4500 ina utendakazi wa kuvutia, tunaweza kutoa utoaji kamili wa IOPS kwa mashine na hifadhi ya chelezo kwa seva mbadala isiyo na IOWAIT.

Sisi ni mmoja wa wale waumini wa zamani ambao hawatumii SDN iliyobadilishwa na vitu vingine vya maridadi, vya mtindo, vya vijana kuhifadhi viwango vya VM, tukiamini kuwa mfumo rahisi, ni rahisi zaidi kuisuluhisha katika hali ya "guru mkuu amekwenda. kwenye milima.” Kwa hivyo, tunahifadhi juzuu za VM katika umbizo la QCOW2 katika XFS au EXT4, ambayo inatumwa juu ya LVM2.

Pia tunalazimika kutumia QCOW2 na bidhaa tunayotumia kwa okestration - Apache CloudStack.

Ili kufanya nakala rudufu, tunachukua picha kamili ya kiasi kama picha ya LVM2 (ndio, tunajua kuwa vijipicha vya LVM2 ni polepole, lakini Intel P4500 hutusaidia hapa pia). Tunafanya lvmcreate -s .. na kwa msaada dd tunatuma nakala ya chelezo kwa seva ya mbali na hifadhi ya ZFS. Hapa bado tunaendelea kidogo - baada ya yote, ZFS inaweza kuhifadhi data katika fomu iliyoshinikwa, na tunaweza kuirejesha haraka kwa kutumia DD au pata kiasi cha VM kwa kutumia mount -o loop ....

Unaweza, kwa kweli, kuondoa sio picha kamili ya kiasi cha LVM2, lakini weka mfumo wa faili kwenye faili ya RO na nakala za picha za QCOW2 wenyewe, hata hivyo, tulikabiliwa na ukweli kwamba XFS ikawa mbaya kutoka kwa hili, na si mara moja, lakini kwa njia isiyotabirika. Kwa kweli hatupendi wakati waandaji wa hypervisor "wanashikamana" ghafla mwishoni mwa wiki, usiku au likizo kutokana na makosa ambayo haijulikani wakati yatatokea. Kwa hivyo, kwa XFS hatutumii uwekaji picha wa ndani RO ili kutoa juzuu, tunakili tu kiasi kizima cha LVM2.

Kasi ya kuhifadhi nakala kwenye seva ya chelezo imedhamiriwa kwa upande wetu na utendakazi wa seva ya chelezo, ambayo ni takriban 600-800 MB/s kwa data isiyoshikika; kikomo zaidi ni chaneli ya 10Gbit/s ambayo seva ya chelezo imeunganishwa. kwa nguzo.

Katika kesi hii, nakala za chelezo za seva 8 za hypervisor hupakiwa wakati huo huo kwenye seva moja ya chelezo. Kwa hivyo, mfumo mdogo wa diski na mtandao wa seva ya chelezo, kwa kuwa polepole, hairuhusu mifumo ndogo ya diski ya majeshi ya hypervisor kupakia, kwani hawawezi kusindika, sema, 8 GB / sec, ambayo mwenyeji wa hypervisor anaweza kwa urahisi. kuzalisha.

Mchakato wa kunakili hapo juu ni muhimu sana kwa hadithi zaidi, ikiwa ni pamoja na maelezo - kwa kutumia gari la haraka la Intel P4500, kwa kutumia NFS na, pengine, kwa kutumia ZFS.

Hadithi ya chelezo

Kwenye kila nodi ya hypervisor tuna kizigeu kidogo cha SWAP cha ukubwa wa GB 8, na "tunatoa" nodi ya hypervisor yenyewe kwa kutumia. DD kutoka kwa picha ya kumbukumbu. Kwa kiasi cha mfumo kwenye seva, tunatumia 2xSATA SSD RAID1 au 2xSAS HDD RAID1 kwenye LSI au kidhibiti cha maunzi cha HP. Kwa ujumla, hatujali chochote kilicho ndani, kwa kuwa kiasi cha mfumo wetu hufanya kazi katika hali ya "karibu kusoma tu", isipokuwa kwa SWAP. Na kwa kuwa tuna RAM nyingi kwenye seva na ni 30-40% ya bure, hatufikiri juu ya SWAP.

Mchakato wa kuhifadhi nakala. Kazi hii inaonekana kama hii:

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

Makini na ionice -c3, kwa kweli, jambo hili halina maana kabisa kwa vifaa vya NVMe, kwani mpangilio wa IO kwao umewekwa kama:

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

Walakini, tuna idadi ya nodi za urithi zilizo na RAID za kawaida za SSD, kwao hii inafaa, kwa hivyo zinasonga. AS IS. Kwa ujumla, hii ni kipande cha msimbo cha kuvutia ambacho kinaelezea ubatili ionice katika kesi ya usanidi kama huo.

Makini na bendera iflag=direct kwa DD. Tunatumia IO ya moja kwa moja kukwepa akiba ya akiba ili kuepuka uingizwaji usio wa lazima wa vibafa vya IO wakati wa kusoma. Hata hivyo, oflag=direct hatufanyi hivyo kwa sababu tumekumbana na masuala ya utendaji wa ZFS tunapoitumia.

Tumekuwa tukitumia mpango huu kwa mafanikio kwa miaka kadhaa bila shida.

Na kisha ilianza... Tuligundua kuwa nodi moja haikuwa na nakala rudufu tena, na ile ya awali ilikuwa ikiendeshwa na IOWAIT ya kutisha ya 50%. Wakati wa kujaribu kuelewa kwa nini kunakili haifanyiki, tulikutana na jambo lifuatalo:

Volume group "images" not found

Tulianza kufikiria "mwisho umefika kwa Intel P4500," hata hivyo, kabla ya kuzima seva ili kuchukua nafasi ya gari, bado ilikuwa ni lazima kufanya nakala rudufu. Tulirekebisha LVM2 kwa kurejesha metadata kutoka kwa nakala rudufu ya LVM2:

vgcfgrestore images

Tulizindua nakala rudufu na tukaona uchoraji huu wa mafuta:

Tena tulihuzunika sana - ilikuwa wazi kuwa hatungeweza kuishi hivi, kwani VPS zote zingeteseka, ambayo inamaanisha kwamba tungeteseka pia. Kilichotokea haijulikani kabisa - iostat ilionyesha IOPS ya kusikitisha na IOWAIT ya juu zaidi. Hakukuwa na maoni isipokuwa "wacha tubadilishe NVMe," lakini ufahamu ulitokea kwa wakati.

Uchambuzi wa hali hiyo hatua kwa hatua

Jarida la kihistoria. Siku chache mapema, kwenye seva hii ilikuwa ni lazima kuunda VPS kubwa na 128 GB RAM. Ilionekana kuwa na kumbukumbu ya kutosha, lakini kuwa upande salama, tulitenga GB 32 nyingine kwa kizigeu cha kubadilishana. VPS iliundwa, ikakamilisha kazi yake kwa mafanikio na tukio hilo lilisahauliwa, lakini kizigeu cha SWAP kilibaki.

Vipengele vya Usanidi. Kwa seva zote za wingu parameta vm.swappiness iliwekwa kuwa chaguomsingi 60. Na SWAP iliundwa kwenye SAS HDD RAID1.

Nini kilifanyika (kulingana na wahariri). Wakati wa kuhifadhi nakala DD ilitoa data nyingi za uandishi, ambazo ziliwekwa kwenye buffers za RAM kabla ya kuandika kwa NFS. Msingi wa mfumo, unaoongozwa na sera swappiness, ilikuwa ikihamisha kurasa nyingi za kumbukumbu ya VPS kwenye eneo la kubadilishana, ambalo lilikuwa kwenye sauti ya polepole ya HDD RAID1. Hii ilisababisha IOWAIT kukua kwa nguvu sana, lakini si kutokana na IO NVMe, lakini kutokana na IO HDD RAID1.

Jinsi tatizo lilitatuliwa. Sehemu ya kubadilishana ya 32GB ilizimwa. Hii ilichukua saa 16; unaweza kusoma kando kuhusu jinsi na kwa nini SWAP inazima polepole sana. Mipangilio imebadilishwa swappiness kwa thamani sawa na 5 juu ya wingu.

Je, hili lisingeweza kutokea?. Kwanza, ikiwa SWAP ilikuwa kwenye kifaa cha SSD RAID au NVMe, na pili, ikiwa hakukuwa na kifaa cha NVMe, lakini kifaa cha polepole ambacho hakingetoa kiasi kama hicho cha data - kwa kushangaza, shida ilitokea kwa sababu NVMe ni haraka sana.

Baada ya hapo, kila kitu kilianza kufanya kazi kama hapo awali - na sifuri IOWAIT.

Chanzo: mapenzi.com