ProHoster > Blogs > Administrācija > Daudz bezmaksas RAM, NVMe Intel P4500 un viss ir ārkārtÄ«gi lēns - stāsts par neveiksmÄ«gu mijmaiņas nodalÄ«juma pievienoÅ”anu

Daudz bezmaksas RAM, NVMe Intel P4500 un viss ir ārkārtÄ«gi lēns - stāsts par neveiksmÄ«gu mijmaiņas nodalÄ«juma pievienoÅ”anu

Å ajā rakstā es runāŔu par situāciju, kas nesen notika ar vienu no mÅ«su VPS mākonÄ« esoÅ”ajiem serveriem, kas mani samulsināja vairākas stundas. Es konfigurēju un veicu Linux serveru problēmu novērÅ”anu aptuveni 15 gadus, taču Å”is gadÄ«jums manā praksē nekādi neiederas - es izdarÄ«ju vairākus nepareizus pieņēmumus un mazliet izmisumā, pirms varēju pareizi noteikt problēmas cēloni un to atrisināt. .

Preambula

Darbojamies ar vidēja izmēra mākoni, kuru veidojam uz standarta serveriem ar Ŕādu konfigurāciju - 32 kodoli, 256 GB RAM un 4500TB PCI-E Intel P4 NVMe diskdzinis. Mums ļoti patÄ«k Ŕī konfigurācija, jo tā novērÅ” nepiecieÅ”amÄ«bu uztraukties par IO pieskaitāmajām izmaksām, nodroÅ”inot pareizos ierobežojumus VM instances tipa lÄ«menÄ«. Tā kā NVMe Intel P4500 ir iespaidÄ«ga veiktspēja, mēs varam vienlaikus nodroÅ”ināt gan pilnu IOPS nodroÅ”ināŔanu maŔīnām, gan rezerves krātuvi rezerves serverÄ« ar nulli IOWAIT.

Mēs esam vieni no tiem vecticÄ«bniekiem, kuri VM sējumu glabāŔanai neizmanto hiperkonverģētu SDN un citas stilÄ«gas, modernas, jaunieÅ”u lietas, uzskatot, ka jo vienkārŔāka sistēma, jo vieglāk to novērst apstākļos, kad ā€œgalvenais guru ir aizgājis. uz kalniem." Rezultātā mēs glabājam VM sējumus QCOW2 formātā XFS vai EXT4 formātā, kas tiek izvietots virs LVM2.

MÅ«s piespiež izmantot arÄ« QCOW2 produkts, ko izmantojam orÄ·estrÄ“Å”anai - Apache CloudStack.

Lai veiktu dublÄ“Å”anu, mēs uzņemam pilnu skaļuma attēlu kā LVM2 momentuzņēmumu (jā, mēs zinām, ka LVM2 momentuzņēmumi ir lēni, taču Intel P4500 mums palÄ«dz arÄ« Å”eit). Mēs darām lvmcreate -s .. un ar palÄ«dzÄ«bu dd mēs nosÅ«tām rezerves kopiju uz attālo serveri ar ZFS krātuvi. Å eit mēs joprojām esam nedaudz progresÄ«vi - galu galā ZFS var uzglabāt datus saspiestā veidā, un mēs varam tos ātri atjaunot, izmantojot DD vai iegÅ«stiet atseviŔķus VM sējumus, izmantojot mount -o loop ....

Protams, jÅ«s varat noņemt nevis pilnu LVM2 sējuma attēlu, bet gan uzstādÄ«t failu sistēmu RO un kopēt paÅ”us QCOW2 attēlus, tomēr mēs saskārāmies ar faktu, ka XFS no tā kļuva slikts, un ne uzreiz, bet gan neparedzamā veidā. Mums ļoti nepatÄ«k, ja hipervizoru saimnieki pēkŔņi ā€œpielÄ«pā€ nedēļas nogalēs, naktÄ«s vai brÄ«vdienās kļūdu dēļ, kuras nav skaidrs, kad tās notiks. Tāpēc XFS mēs neizmantojam momentuzņēmuma montāžu RO lai iegÅ«tu apjomus, mēs vienkārÅ”i nokopējam visu LVM2 sējumu.

DublÄ“Å”anas ātrumu uz rezerves serveri mÅ«su gadÄ«jumā nosaka rezerves servera veiktspēja, kas ir aptuveni 600-800 MB/s nesaspiežamiem datiem, vēl viens ierobežotājs ir 10Gbit/s kanāls, ar kuru ir savienots rezerves serveris. uz klasteru.

Å ajā gadÄ«jumā 8 hipervizora serveru rezerves kopijas vienlaikus tiek augÅ”upielādētas vienā rezerves serverÄ«. Tādējādi rezerves servera diska un tÄ«kla apakÅ”sistēmas, bÅ«dami lēnākas, neļauj hipervizora saimniekdatoru diska apakÅ”sistēmām pārslogot, jo tās vienkārÅ”i nespēj apstrādāt, teiksim, 8 GB/s, ko hipervizora resursdatori var viegli. ražot.

Augstāk minētais kopÄ“Å”anas process ir ļoti bÅ«tisks tālākajam stāstam, tai skaitā detaļām - izmantojot ātro Intel P4500 disku, izmantojot NFS un, iespējams, izmantojot ZFS.

Rezerves stāsts

Katrā hipervizora mezglā mums ir mazs SWAP nodalÄ«jums 8 GB lielumā, un mēs ā€œizlaižamā€ paÅ”u hipervizora mezglu, izmantojot DD no atsauces attēla. Sistēmas apjomam serveros mēs izmantojam 2xSATA SSD RAID1 vai 2xSAS HDD RAID1 uz LSI vai HP aparatÅ«ras kontrollera. Kopumā mums ir vienalga, kas ir iekŔā, jo mÅ«su sistēmas apjoms darbojas ā€œgandrÄ«z tikai lasÄ«Å”anasā€ režīmā, izņemot SWAP. Un tā kā mums serverÄ« ir daudz RAM un tā ir 30ā€“40% bez maksas, mēs nedomājam par SWAP.

DublÄ“Å”anas process. Å is uzdevums izskatās apmēram Ŕādi:

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

Ņemiet ionice -c3, patiesÄ«bā Ŕī lieta ir pilnÄ«gi bezjēdzÄ«ga NVMe ierÄ«cēm, jo ā€‹ā€‹tām ir iestatÄ«ts IO plānotājs:

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

Tomēr mums ir vairāki mantoti mezgli ar parastajiem SSD RAID, tiem tas ir svarÄ«gi, tāpēc tie pārvietojas KĀ IR. Kopumā tas ir tikai interesants koda fragments, kas izskaidro bezjēdzÄ«bu ionice Ŕādas konfigurācijas gadÄ«jumā.

Pievērsiet uzmanÄ«bu karogam iflag=direct par DD. Mēs izmantojam tieÅ”o IO, apejot bufera keÅ”atmiņu, lai lasÄ«Å”anas laikā izvairÄ«tos no nevajadzÄ«gas IO buferu nomaiņas. tomēr oflag=direct mēs to nedarām, jo, to lietojot, esam saskāruÅ”ies ar ZFS veiktspējas problēmām.

Šo shēmu veiksmīgi lietojam jau vairākus gadus bez problēmām.

Un tad tas sākās... Mēs atklājām, ka viens no mezgliem vairs nav dublēts, un iepriekŔējais darbojās ar milzÄ«gu IOWAIT 50%. Mēģinot saprast, kāpēc kopÄ“Å”ana nenotiek, mēs saskārāmies ar Ŕādu parādÄ«bu:

Volume group "images" not found

Sākām domāt par ā€œIntel P4500 beigasā€, tomēr pirms servera izslēgÅ”anas, lai nomainÄ«tu disku, tomēr bija nepiecieÅ”ams veikt dublÄ“Å”anu. Mēs labojām LVM2, atjaunojot metadatus no LVM2 dublējuma:

vgcfgrestore images

Mēs uzsākām dublÄ“Å”anu un redzējām Å”o eļļas gleznu:
Daudz bezmaksas RAM, NVMe Intel P4500 un viss ir ārkārtÄ«gi lēns - stāsts par neveiksmÄ«gu mijmaiņas nodalÄ«juma pievienoÅ”anu

Atkal bijām ļoti skumji ā€“ bija skaidrs, ka tā dzÄ«vot nevaram, jo ā€‹ā€‹cietÄ«s visi VPS, tas nozÄ«mē, ka cietÄ«sim arÄ« mēs. Kas notika, ir pilnÄ«gi neskaidrs - iostat parādÄ«ja nožēlojamu IOPS un augstāko IOWAIT. Nebija citu ideju kā vien ā€œnomaināsim NVMeā€, taču ieskats radās tieÅ”i laikā.

Situācijas analīze soli pa solim

Vēsturisks žurnāls. Dažas dienas iepriekÅ” Å”ajā serverÄ« bija nepiecieÅ”ams izveidot lielu VPS ar 128 GB RAM. Å Ä·ita, ka atmiņas ir pietiekami daudz, taču, lai bÅ«tu droŔībā, mēs pieŔķīrām vēl 32 GB mijmaiņas nodalÄ«jumam. VPS tika izveidots, veiksmÄ«gi izpildÄ«ja savu uzdevumu un incidents tika aizmirsts, bet SWAP nodalÄ«jums palika.

Konfigurācijas līdzekļi. Visiem mākoņa serveriem parametrs vm.swappiness tika iestatīts uz noklusējuma 60. Un SWAP tika izveidots SAS HDD RAID1.

Kas notika (pēc redaktoru domām). Veicot dublÄ“Å”anu DD radÄ«ja daudz rakstÄ«Å”anas datu, kas tika ievietoti RAM buferos pirms rakstÄ«Å”anas uz NFS. Sistēmas kodols, vadoties pēc politikas swappiness, pārvietoja daudzas VPS atmiņas lapas uz mijmaiņas apgabalu, kas atradās lēnā HDD RAID1 sējumā. Tas noveda pie tā, ka IOWAIT ļoti strauji pieauga, bet ne IO NVMe, bet gan IO HDD RAID1 dēļ.

Kā problēma tika atrisināta. 32 GB mijmaiņas nodalÄ«jums tika atspējots. Tas aizņēma 16 stundas; varat lasÄ«t atseviŔķi par to, kā un kāpēc SWAP izslēdzas tik lēni. IestatÄ«jumi ir mainÄ«ti swappiness lÄ«dz vērtÄ«bai, kas vienāda ar 5 pa visu mākoni.

Kā tas varēja nenotikt?. Pirmkārt, ja SWAP būtu SSD RAID vai NVMe ierīcē, un, otrkārt, ja nebūtu NVMe ierīces, bet gan lēnāka ierīce, kas neradītu tādu datu apjomu - ironiskā kārtā problēma radās tāpēc, ka NVMe ir pārāk ātrs.

Pēc tam viss sāka darboties kā iepriekÅ” - ar nulli IOWAIT.

Avots: www.habr.com

Pievieno komentāru