Көптөгөн акысыз RAM, NVMe Intel P4500 жана баары өтө жай - алмашуу бөлүгүн ийгиликсиз кошуу окуясы

Бул макалада мен жакында эле VPS булутубуздагы серверлердин бири менен болгон кырдаал жөнүндө айтып берем, ал мени бир нече саатка таң калтырды. Мен 15 жылдан бери Linux серверлерин конфигурациялап, көйгөйлөрдү чечип келе жатам, бирок бул иш менин практикама такыр туура келбейт - мен бир нече жалган божомолдорду жасап, маселенин себебин туура аныктап, аны чечкенге чейин бир аз кыйналдым. .

преамбула

Биз орто көлөмдөгү булутту иштетебиз, аны төмөнкү конфигурациядагы стандарттык серверлерге курабыз - 32 өзөк, 256 ГБ оперативдүү эс жана 4500TB PCI-E Intel P4 NVMe диск. Бизге бул конфигурация абдан жагат, анткени ал VM инстанция түрүнүн деңгээлинде туура чектөөнү камсыз кылуу менен IO кошумча чыгымдары жөнүндө тынчсыздануунун зарылдыгын жок кылат. Анткени NVMe Intel P4500 таасирдүү аткарууга ээ, биз бир эле учурда машиналарды толук IOPS камсыздоону жана нөл IOWAIT менен резервдик серверге камдык сактоону камсыздай алабыз.

Биз VM көлөмдөрүн сактоо үчүн гиперконвергацияланган SDN жана башка стилдүү, модалуу, жаштарга таандык нерселерди колдонбогон эски ишенгендердин бирибиз, система канчалык жөнөкөй болсо, "негизги гуру кетти" шарттарында аны оңдоо ошончолук оңой болот деп ишенебиз. тоолорго." Натыйжада, биз VM томдорун QCOW2 форматында XFS же EXT4 форматында сактайбыз, ал LVM2 үстүнө жайгаштырылган.

Биз ошондой эле QCOW2ди биз оркестрлөө үчүн колдонгон продукт - Apache CloudStack менен колдонууга аргасыз болуп жатабыз.

Камдык көчүрмөнү аткаруу үчүн, LVM2 сүрөтү катары көлөмдүн толук сүрөтүн алабыз (ооба, LVM2 сүрөтү жай экенин билебиз, бирок Intel P4500 бизге бул жерде да жардам берет). Биз жасап жатабыз lvmcreate -s .. жана жардамы менен dd биз камдык көчүрмөнү ZFS сактагычы бар алыскы серверге жөнөтөбүз. Бул жерде биз дагы эле бир аз прогрессивдүү - акыры, ZFS маалыматтарды кысылган түрдө сактай алат жана биз аны колдонуу менен тез калыбына келтире алабыз. DD же жеке VM көлөмүн алуу mount -o loop ....

Сиз, албетте, LVM2 томунун толук сүрөтүн жок кыла аласыз, бирок файл тутумун орнотсоңуз болот RO жана QCOW2 сүрөттөрүнүн өздөрүн көчүрүңүз, бирок биз XFS дароо эле эмес, күтүлбөгөн жерден жаман болуп калганына туш болдук. Гипервизордун хосттор дем алыш күндөрү, түнкүсүн же майрамдарда капысынан "жабышып", каталардын качан болоору белгисиз болгондуктан, бизге чындап эле жакпайт. Ошондуктан, XFS үчүн биз снапшот орнотууну колдонбойбуз RO томдорду алуу үчүн, биз жөн гана бүт LVM2 көлөмүн көчүрүп.

Резервдик серверге резервдик көчүрүүнүн ылдамдыгы биздин учурда резервдик сервердин иштеши менен аныкталат, ал кысылбаган маалыматтар үчүн болжол менен 600-800 МБ/с түзөт; кийинки чектөөчү резервдик сервер туташтырылган 10 Гбит/с канал болуп саналат. кластерге.

Бул учурда, 8 гипервизор серверинин резервдик көчүрмөлөрү бир эле учурда бир резервдик серверге жүктөлөт. Ошентип, резервдик сервердин диск жана тармактык подсистемалары жайыраак болгондуктан, гипервизордун хостторунун дисктик подсистемаларынын ашыкча жүктөлүшүнө жол бербейт, анткени алар жөн эле иштете алышпайт, айталы, 8 ГБ/сек, аны гипервизордун хосттору оңой эле иштете алат. өндүрүү.

Жогорудагы көчүрүү процесси кийинки окуя үчүн абдан маанилүү, анын ичинде деталдар - тез Intel P4500 дискин колдонуу, NFS жана, кыязы, ZFS колдонуу.

Камдык окуя

Ар бир гипервизор түйүнүндө бизде 8 ГБ өлчөмүндөгү кичинекей SWAP бөлүмү бар жана биз гипервизор түйүнүнүн өзүн "чыгарып" жатабыз. DD шилтеме сүрөтүнөн. Серверлердеги системанын көлөмү үчүн биз LSI же HP аппараттык контроллерунда 2xSATA SSD RAID1 же 2xSAS HDD RAID1 колдонобуз. Жалпысынан алганда, биздин тутумдун көлөмү SWAP режиминен тышкары, "дээрлик окуу үчүн гана" режимде иштегендиктен, ичинде эмне бар экени бизге таптакыр кызыкдар эмес. Ал эми серверде RAM көп болгондуктан жана ал 30-40% бекер болгондуктан, биз SWAP жөнүндө ойлонбойбуз.

Камдык көчүрмөнү сактоо процесси. Бул тапшырма төмөнкүдөй көрүнөт:

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

сак болгула ionice -c3, чындыгында, бул нерсе NVMe түзмөктөрү үчүн таптакыр пайдасыз, анткени алар үчүн IO пландоочу төмөнкүдөй орнотулган:

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

Бирок, бизде кадимки SSD RAIDдери бар бир катар эски түйүндөр бар, алар үчүн бул актуалдуу, ошондуктан алар жылып жатышат БОЛГОНДОЙ. Жалпысынан алганда, бул жөн гана пайдасыздыгын түшүндүргөн кызыктуу код ionice мындай конфигурация болгон учурда.

Желекке көңүл буруңуз iflag=direct үчүн DD. Окуу учурунда IO буферлерин ашыкча алмаштырууну болтурбоо үчүн буфердик кэшти айланып өтүп түз IO колдонобуз. Бирок, oflag=direct биз аны колдонууда ZFS иштешине байланыштуу көйгөйлөргө туш болгонубуз үчүн эмес.

Биз бул схеманы бир нече жылдан бери көйгөйсүз ийгиликтүү колдонуп келебиз.

Анан башталды... Биз түйүндөрдүн биринин камдык көчүрмөсү болбой калганын, ал эми мурункусу 50% коркунучтуу IOWAIT менен иштеп жатканын аныктадык. Көчүрүү эмне үчүн болбой жатканын түшүнүүгө аракет кылып жатканда, биз төмөнкү көрүнүшкө туш болдук:

Volume group "images" not found

Биз "Intel P4500 үчүн аягы келди" деп ойлоно баштадык, бирок дискти алмаштыруу үчүн серверди өчүрүүдөн мурун дагы эле резервдик көчүрмөнү жасоо керек болчу. LVM2 камдык көчүрмөсүнөн метадайындарды калыбына келтирүү менен LVM2ди оңдодук:

vgcfgrestore images

Биз камдык көчүрмөнү ишке киргизип, бул майлуу сүрөттү көрдүк:

Биз дагы абдан капа болдук - биз ушинтип жашай албасыбыз айкын болду, анткени бардык VPSтер жапа чегишет, демек, биз да кыйналабыз. Эмне болгону түшүнүксүз - iostat аянычтуу IOPS жана эң жогорку IOWAIT көрсөттү. "NVMe алмаштыралы" дегенден башка эч кандай идеялар болгон жок, бирок түшүнүк өз убагында болду.

Кырдаалды этап-этабы менен талдоо

Тарыхый журнал. Бир нече күн мурун, бул серверде 128 ГБ оперативдүү эс тутум менен чоң VPS түзүү керек болчу. Эстутум жетиштүү окшойт, бирок коопсуз болушу үчүн, биз алмашуу бөлүмү үчүн дагы 32 ГБ бөлдүк. VPS түзүлдү, өз милдетин ийгиликтүү аткарып, окуя унутулуп калды, бирок SWAP бөлүмү калды.

Конфигурация өзгөчөлүктөрү. Бардык булут серверлери үчүн параметр vm.swappiness демейкиге коюлган 60. Ал эми SWAP SAS HDD RAID1де түзүлгөн.

Эмне болду (редакциянын айтымында). Камдык көчүрмөнү сактоодо DD NFSге жазуудан мурун RAM буферлерине жайгаштырылган көптөгөн жазуу маалыматтарын өндүргөн. Саясаттын негизинде системанын өзөгү swappiness, жай HDD RAID1 көлөмүндө жайгашкан алмашуу аймагына VPS эс тутумунун көптөгөн баракчаларын жылдырып жатты. Бул IOWAITтин абдан күчтүү өсүшүнө алып келди, бирок IO NVMe эмес, IO HDD RAID1 эсебинен.

Маселе кантип чечилди. 32 ГБ алмашуу бөлүмү өчүрүлгөн. Бул 16 саатка созулду; SWAP кантип жана эмне үчүн мынчалык жай өчүп калганын өзүнчө окуй аласыз. Орнотуулар өзгөртүлдү swappiness барабар мааниге 5 бардык булуттун үстүндө.

Кантип мындай болбошу мүмкүн?. Биринчиден, эгерде SWAP SSD RAID же NVMe түзмөгүндө болсо, экинчиден, NVMe түзмөгү жок болсо, бирок мынчалык көлөмдөгү маалыматтарды чыгара албаган жайыраак түзмөк болсо - тамашасы, көйгөй ошол NVMe өтө тез болгондуктан келип чыккан.

Андан кийин, баары мурункудай иштей баштады - нөл IOWAIT менен.

Source: www.habr.com