Shumë RAM falas, NVMe Intel P4500 dhe gjithçka është jashtëzakonisht e ngadaltë - historia e shtimit të pasuksesshëm të një ndarjeje shkëmbimi

Në këtë artikull, unë do të flas për një situatë që ka ndodhur kohët e fundit me një nga serverët në renë tonë VPS, e cila më la të hutuar për disa orë. Unë kam konfiguruar dhe zgjidhur problemet e serverëve Linux për rreth 15 vjet, por ky rast nuk përshtatet fare në praktikën time - bëra disa supozime të rreme dhe u dëshpërova pak para se të isha në gjendje të përcaktoja saktë shkakun e problemit dhe ta zgjidhja atë .

Преамбула

Ne operojmë një re me madhësi mesatare, të cilën e ndërtojmë në serverë standardë me konfigurimin e mëposhtëm - 32 bërthama, 256 GB RAM dhe një disk PCI-E Intel P4500 NVMe 4 TB. Na pëlqen shumë ky konfigurim sepse eliminon nevojën për t'u shqetësuar për shpenzimet e përgjithshme të IO duke siguruar kufizimin e saktë në nivelin e llojit të shembullit VM. Sepse NVMe Intel P4500 ka performancë mbresëlënëse, ne mund të ofrojmë njëkohësisht furnizim të plotë IOPS për makinat dhe ruajtje rezervë në një server rezervë me IOWAIT zero.

Ne jemi një nga ata besimtarë të vjetër që nuk përdorim SDN të hiperkonverguar dhe gjëra të tjera elegante, në modë, rinore për të ruajtur vëllimet e VM-së, duke besuar se sa më i thjeshtë të jetë sistemi, aq më lehtë është zgjidhja e tij në kushtet e "guru kryesor ka ikur. në male.” Si rezultat, ne ruajmë vëllimet VM në formatin QCOW2 në XFS ose EXT4, i cili vendoset në krye të LVM2.

Ne jemi gjithashtu të detyruar të përdorim QCOW2 nga produkti që përdorim për orkestrim - Apache CloudStack.

Për të kryer një kopje rezervë, ne bëjmë një imazh të plotë të volumit si një fotografi LVM2 (po, ne e dimë që fotografitë e LVM2 janë të ngadalta, por Intel P4500 na ndihmon edhe këtu). Ne bejme lvmcreate -s .. dhe me ndihmën dd ne dërgojmë kopjen rezervë në një server në distancë me hapësirë ​​ruajtëse ZFS. Këtu ne jemi ende pak progresiv - në fund të fundit, ZFS mund të ruajë të dhënat në formë të ngjeshur dhe ne mund t'i rivendosim ato shpejt duke përdorur DD ose merrni vëllime individuale VM duke përdorur mount -o loop ....

Sigurisht, nuk mund të hiqni imazhin e plotë të vëllimit LVM2, por të montoni sistemin e skedarëve në RO dhe kopjoni vetë imazhet QCOW2, megjithatë, ne u përballëm me faktin se XFS u bë i keq nga kjo, dhe jo menjëherë, por në një mënyrë të paparashikueshme. Nuk na pëlqen shumë kur hostet e hipervizorit "ngjiten" papritmas gjatë fundjavave, natës ose pushimeve për shkak të gabimeve që nuk janë të qarta se kur do të ndodhin. Prandaj, për XFS ne nuk përdorim montimin e fotografive RO për të nxjerrë vëllime, ne thjesht kopjojmë të gjithë vëllimin LVM2.

Shpejtësia e kopjimit në serverin rezervë përcaktohet në rastin tonë nga performanca e serverit rezervë, e cila është rreth 600-800 MB/s për të dhëna të pakompresueshme; një kufizues tjetër është kanali 10 Gbit/s me të cilin lidhet serveri rezervë. te grupi.

Në këtë rast, kopjet rezervë të 8 serverëve hipervizor ngarkohen njëkohësisht në një server rezervë. Kështu, nënsistemet e diskut dhe të rrjetit të serverit rezervë, duke qenë më të ngadalshëm, nuk lejojnë që nënsistemet e diskut të hosteve të hipervizorit të mbingarkohen, pasi ato thjesht nuk janë në gjendje të përpunojnë, të themi, 8 GB/sek, të cilat hostet e hipervizorit mund ta bëjnë lehtësisht. prodhojnë.

Procesi i mësipërm i kopjimit është shumë i rëndësishëm për historinë e mëtejshme, duke përfshirë detajet - duke përdorur një makinë të shpejtë Intel P4500, duke përdorur NFS dhe, ndoshta, duke përdorur ZFS.

Historia rezervë

Në secilën nyje të hipervizorit ne kemi një ndarje të vogël SWAP me madhësi 8 GB, dhe ne "përfshijmë" vetë nyjen e hipervizorit duke përdorur DD nga imazhi i referencës. Për vëllimin e sistemit në serverë, ne përdorim 2xSATA SSD RAID1 ose 2xSAS HDD RAID1 në një kontrollues hardueri LSI ose HP. Në përgjithësi, nuk na intereson fare se çfarë ka brenda, pasi vëllimi i sistemit tonë funksionon në modalitetin "pothuajse vetëm për lexim", përveç SWAP. Dhe meqenëse kemi shumë RAM në server dhe është 30-40% falas, ne nuk mendojmë për SWAP.

Procesi i rezervimit. Kjo detyrë duket diçka si kjo:

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

Kushtojini vëmendje ionice -c3, në fakt, kjo gjë është plotësisht e padobishme për pajisjet NVMe, pasi planifikuesi IO për to është vendosur si:

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

Sidoqoftë, ne kemi një numër nyjesh të trashëguara me RAID konvencionale SSD, për ta kjo është e rëndësishme, kështu që ata po lëvizin SIC ËSHTË. Në përgjithësi, kjo është vetëm një pjesë interesante e kodit që shpjegon kotësinë ionice në rast të një konfigurimi të tillë.

Kushtojini vëmendje flamurit iflag=direct për DD. Ne përdorim IO direkte duke anashkaluar cache-in e tamponit për të shmangur zëvendësimin e panevojshëm të buferave IO gjatë leximit. Megjithatë, oflag=direct ne nuk e bëjmë sepse kemi hasur probleme të performancës ZFS kur e përdorim atë.

Ne e përdorim këtë skemë me sukses prej disa vitesh pa probleme.

Dhe pastaj filloi... Ne zbuluam se njëra prej nyjeve nuk ishte më e mbështetur dhe e mëparshmja po funksiononte me një IOWAIT monstruoz prej 50%. Kur u përpoqëm të kuptonim pse nuk ndodh kopjimi, hasëm fenomenin e mëposhtëm:

Volume group "images" not found

Ne filluam të mendojmë për "fundi për Intel P4500 ka ardhur", megjithatë, përpara se të fiknim serverin për të zëvendësuar diskun, ishte ende e nevojshme të kryhej një kopje rezervë. Ne rregulluam LVM2 duke rivendosur meta të dhënat nga një kopje rezervë e LVM2:

vgcfgrestore images

Ne lançuam një kopje rezervë dhe pamë këtë pikturë vaji:

Përsëri ishim shumë të trishtuar - ishte e qartë që nuk mund të jetonim kështu, pasi të gjithë VPS-të do të vuanin, që do të thotë se do të vuanim edhe ne. Ajo që ndodhi është plotësisht e paqartë - iostat tregoi IOPS të mjerueshme dhe IOWAIT më të lartë. Nuk kishte asnjë ide tjetër përveç "le të zëvendësojmë NVMe", por një pasqyrë ndodhi pikërisht në kohë.

Analiza e situatës hap pas hapi

Revistë historike. Disa ditë më parë, në këtë server ishte e nevojshme të krijohej një VPS i madh me 128 GB RAM. Dukej se kishte memorie të mjaftueshme, por për të qenë në anën e sigurt, ne ndamë 32 GB të tjera për ndarjen e shkëmbimit. VPS u krijua, përfundoi me sukses detyrën e tij dhe incidenti u harrua, por ndarja SWAP mbeti.

Karakteristikat e konfigurimit. Për të gjithë serverët cloud, parametri vm.swappiness ishte vendosur në parazgjedhje 60. Dhe SWAP u krijua në SAS HDD RAID1.

Çfarë ndodhi (sipas redaktorëve). Kur bëni kopje rezervë DD prodhoi shumë të dhëna shkrimi, të cilat u vendosën në buferat e RAM-it përpara se të shkruanin në NFS. Thelbi i sistemit, i udhëhequr nga politika swappiness, po lëvizte shumë faqe të memories VPS në zonën e shkëmbimit, e cila ndodhej në një vëllim të ngadaltë HDD RAID1. Kjo bëri që IOWAIT të rritet shumë fuqishëm, por jo për shkak të IO NVMe, por për shkak të IO HDD RAID1.

Si u zgjidh problemi. Ndarja e shkëmbimit 32 GB u çaktivizua. Kjo zgjati 16 orë; mund të lexoni veçmas se si dhe pse SWAP fiket kaq ngadalë. Cilësimet janë ndryshuar swappiness në një vlerë të barabartë me 5 në të gjithë renë.

Si mund të mos ndodhte kjo?. Së pari, nëse SWAP do të ishte në një pajisje SSD RAID ose NVMe, dhe së dyti, nëse nuk do të kishte pajisje NVMe, por një pajisje më të ngadaltë që nuk do të prodhonte një vëllim të tillë të dhënash - për ironi, problemi ndodhi sepse ai NVMe është shumë i shpejtë.

Pas kësaj, gjithçka filloi të funksionojë si më parë - me zero IOWAIT.

Burimi: www.habr.com