Gelek RAM-a belaş, NVMe Intel P4500 û her tişt pir hêdî ye - çîroka zêdekirina neserkeftî ya dabeşek guheztinê

Di vê gotarê de, ez ê li ser rewşek biaxivim ku vê dawiyê bi yek ji serverên di ewrê meya VPS-ê de qewimî, ku ez çend demjimêran matmayî hiştim. Nêzîkî 15 sal in ku ez serverên Linux-ê mîheng dikim û pirsgirêkan derdixim, lê ev doz qet di pratîka min de cîh nagire - min çend texmînên derewîn çêkirin û hinekî bêhêvî bûm berî ku ez bikaribim sedema pirsgirêkê rast diyar bikim û wê çareser bikim. .

Preamble

Em ewrek navîn-navîn dixebitin, ku em li ser serverên standard bi veavakirina jêrîn ava dikin - 32 core, 256 GB RAM û ajokerek 4500TB PCI-E Intel P4 NVMe. Em bi rastî ji vê veavakirinê hez dikin ji ber ku ew bi peydakirina sînorkirina rast di asta celebê nimûneya VM-ê de hewcedariya xeman li ser serê IO ji holê radike. Ji ber ku NVMe Intel P4500 xwedan performansa berbiçav e, em dikarin di heman demê de hem dabînkirina IOPS-a tevahî ji makîneyan re û hem jî hilanîna hilanînê ji serverek hilanînê ya bi IOWAIT-a sifir re peyda bikin.

Em yek ji wan bawermendên kevn in ku SDN-ya hyperconverged û tiştên din ên şêwaz, moda, ciwan bikar naynin da ku cildên VM-yê hilînin, di wê baweriyê de ne ku her ku pergal sadetir be, ew qas hêsan e ku meriv wê di şert û mercên "guruyê sereke çûye" de çareser bike. ber bi çiyayan ve diçin.” Wekî encamek, em cildên VM-ê di formata QCOW2 de di XFS an EXT4 de, ku li ser LVM2-ê hatî bicîh kirin, hilînin.

Di heman demê de em neçar in ku QCOW2-ê ji hêla hilbera ku em ji bo orkestrasyonê bikar tînin bikar bînin - Apache CloudStack.

Ji bo pêkanîna paşvekişandinê, em wêneyek tevahî ya dengdanê wekî wêneyek LVM2 digirin (erê, em dizanin ku dîmenên LVM2 hêdî ne, lê Intel P4500 jî li vir ji me re dibe alîkar). Em dikin lvmcreate -s .. û bi alîkariyê dd em kopiyek hilanînê ji serverek dûr a bi hilanîna ZFS re dişînin. Li vir em hîn jî hinekî pêşkeftî ne - her tiştî, ZFS dikare daneyan di forma pêçandî de hilîne, û em dikarin zû bi karanîna wê sererast bikin. DD an jî cildên VM-ê yên kesane bikar bînin mount -o loop ....

Hûn dikarin, bê guman, ne wêneya tevahî ya volume LVM2 jêbirin, lê pergala pelê di nav de siwar bikin RO û wêneyên QCOW2 bi xwe kopî bikin, lêbelê, em bi vê yekê re rû bi rû bûn ku XFS ji vê yekê xirab bû, û ne tavilê, lê bi rengek nepêşbînîkirî. Em bi rastî jê hez nakin dema ku mêvandarên hypervisor ji nişka ve di dawiya hefteyê de, bi şev an jî betlaneyan ji ber xeletiyên ku ne diyar in dê kengê biqewimin, ji nişkê ve "diqelişin". Ji ber vê yekê, ji bo XFS-ê em moda hilgirtina wêneyê bikar naynin RO ji bo derxistina cildan, em bi tenê tevahiya cildê LVM2 kopî dikin.

Leza paşvekişandina servera paşvekişandinê di rewşa me de ji hêla performansa servera hilanînê ve, ku ji bo daneya nehevkirî 600-800 MB/s e, tê destnîşankirin; sînordarek din kanala 10 Gbit/s e ku servera hilanînê pê ve girêdayî ye. ber bi komê ve.

Di vê rewşê de, kopiyên hilanînê yên 8 pêşkêşkerên hîpervisor bi hevdemî li yek serverek hilanînê têne barkirin. Ji ber vê yekê, bine pergalên dîskê û torê yên servera hilanînê, hêdîtir in, nahêlin ku bine pergalên dîskê yên mêvandarên hîpervisor zêde bar bikin, ji ber ku ew bi hêsanî nikarin pêvajoyê bikin, wek nimûne, 8 GB / sec, ku mêvandarên hypervisor bi hêsanî dikarin pêva bikin. çêkirin.

Pêvajoya kopîkirina jorîn ji bo çîroka din, tevî hûrguliyan, pir girîng e - karanîna ajokerek Intel P4500 ya bilez, karanîna NFS û, belkî, karanîna ZFS.

Çîroka Backup

Li ser her girêka hîpervisorê me perçeyek SWAP-ya piçûk a bi mezinahiya 8 GB heye, û em bi xwe girêka hîpervisorê "derdixin" DD ji wêneyê referansê. Ji bo qebareya pergalê li ser serveran, em 2xSATA SSD RAID1 an 2xSAS HDD RAID1 li ser kontrolkerek hardware LSI an HP bikar tînin. Bi gelemperî, em qet eleqedar nakin ka hundurê çi ye, ji ber ku hêjmara pergala me di moda "hema tenê xwendinê" de dixebite, ji bilî SWAP. Û ji ber ku em li ser serverê gelek RAM hene û ew 30-40% belaş e, em li ser SWAP nafikirin.

pêvajoya Backup. Ev kar tiştekî wiha xuya dike:

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

Tê payîn ionice -c3, bi rastî, ev tişt ji bo cîhazên NVMe bi tevahî bêkêr e, ji ber ku nexşerêya IO ji bo wan wekî:

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

Lêbelê, me bi RAID-yên SSD-ya kevneşopî re gelek girêkên mîras hene, ji bo wan ev têkildar e, ji ber vê yekê ew diçin WEK. Bi tevayî, ev tenê kodek balkêş e ku bêkêmasî rave dike ionice di rewşeke wisa de veavakirina.

Bala xwe bidin alê iflag=direct bo DD. Em IO-ya rasterast bikar tînin ku cache tampon derbas dike da ku di dema xwendinê de ji veguheztina nehewce ya tamponên IO dûr bixin. Lebê, oflag=direct em nabêjin ji ber ku dema ku em bikar tînin me bi pirsgirêkên performansa ZFS re rû bi rû maye.

Em çend salan bêyî pirsgirêk vê nexşeyê bi serfirazî bikar tînin.

Û paşê dest pê kir... Me kifş kir ku yek ji girêkan êdî nayê piştguh kirin, û ya berê bi IOWAITek cinawir a 50% dimeşiya. Dema ku em hewl didin ku fêm bikin ka çima kopîkirin çênabe, em rastî diyardeya jêrîn hatin:

Volume group "images" not found

Me dest pê kir ku li ser "dawî ji Intel P4500 re hat" fikirîn, lêbelê, berî ku serverê biguhezîne da ku ajokerê biguhezîne, hîn jî hewce bû ku paşvekişandinek were çêkirin. Me LVM2 bi vegerandina metadata ji paşgirek LVM2 rast kir:

vgcfgrestore images

Me piştgiriyek dest pê kir û ev wêneya rûnê dît:

Dîsa em pir xemgîn bûn - diyar bû ku em nekarin bi vî rengî bijîn, ji ber ku dê hemî VPS cefayê bikişîne, ku tê vê wateyê ku em ê jî cefayê bikişînin. Çi qewimî bi tevahî ne diyar e - iostat IOPS xemgîn û IOWAIT ya herî bilind nîşan da. Ji bilî "werin em NVMe biguhezînin" ti raman tune bûn, lê têgihîştinek di wextê de çêbû.

Analîzkirina rewşê gav bi gav

Kovara dîrokî. Çend roj berê, li ser vê serverê hewce bû ku VPS-ya mezin bi 128 GB RAM were afirandin. Wusa dixuye ku bîranîn têra xwe heye, lê ji bo ku em li aliyek ewle bin, me 32 GB din ji bo dabeşkirina guheztinê veqetand. VPS hate afirandin, karê xwe bi serfirazî qedand û bûyer hate ji bîr kirin, lê dabeşkirina SWAP ma.

Taybetmendiyên Veavakirinê. Ji bo hemî pêşkêşkerên ewr parametre vm.swappiness wek default hate danîn 60. Û SWAP li ser SAS HDD RAID1 hate afirandin.

Çi qewimî (li gorî edîtoran). Dema ku piştgir DD gelek daneyên nivîsandinê hilberandin, ku berî nivîsandina NFS-ê di tamponên RAM-ê de hate danîn. Pergala bingehîn, ji hêla siyasetê ve tê rêve kirin swappiness, gelek rûpelên bîranîna VPS-ê diguhezand devera guheztinê, ku li ser dengek HDD RAID1-ê hêdî bû. Ev bû sedem ku IOWAIT pir bi hêz mezin bibe, lê ne ji ber IO NVMe, lê ji ber IO HDD RAID1.

Pirsgirêk çawa çareser bû. Dabeşkirina guheztinê ya 32 GB hate asteng kirin. Vê yekê 16 demjimêr girt; hûn dikarin ji hev cuda bixwînin ka çawa û çima SWAP ew qas hêdî hêdî qut dibe. Mîheng hatin guhertin swappiness bi nirxek wekhev 5 hemû li ser ewr.

Çawa dibe ku ev yek nebe?. Ya yekem, heke SWAP li ser cîhazek SSD RAID an NVMe bû, û ya duyemîn jî, heke amûrek NVMe tune bû, lê amûrek hêdîtir ku dê hêjmarek daneya wusa çênebe - bi îronîkî, pirsgirêk çêbû ji ber ku ew NVMe pir zû ye.

Piştî wê, her tişt wekî berê dest pê kir - bi sifir IOWAIT.

Source: www.habr.com