Daug laisvos RAM, NVMe Intel P4500 ir viskas labai lėta - istorija apie nesėkmingą apsikeitimo skaidinio pridėjimą

Šiame straipsnyje pakalbėsiu apie situaciją, kuri neseniai įvyko su vienu iš mūsų VPS debesyje esančių serverių, dėl kurios kelias valandas buvau priblokštas. Aš konfigūruoju ir šalinau Linux serverius apie 15 metų, tačiau šis atvejis visiškai netinka mano praktikai – padariau keletą klaidingų prielaidų ir šiek tiek nusiminiau, kol sugebėjau teisingai nustatyti problemos priežastį ir ją išspręsti. .

Preambulė

Valdome vidutinio dydžio debesį, kurį statome standartiniuose serveriuose su tokia konfigūracija – 32 branduoliai, 256 GB RAM ir 4500TB PCI-E Intel P4 NVMe diskas. Mums labai patinka ši konfigūracija, nes ji pašalina poreikį nerimauti dėl IO pridėtinių išlaidų, nes pateikia teisingą apribojimą VM egzemplioriaus tipo lygiu. Kadangi NVMe Intel P4500 turi įspūdingą našumą, vienu metu galime teikti tiek pilną IOPS aprūpinimą įrenginiams, tiek atsarginę saugyklą atsarginiam serveriui su nuliu IOWAIT.

Esame vieni iš tų sentikių, kurie VM tomams saugoti nenaudoja hiperkonverguoto SDN ir kitų stilingų, madingų, jaunimo dalykų, manydami, kad kuo paprastesnė sistema, tuo lengviau ją šalinti „pagrindinio guru išėjo“ sąlygomis. į kalnus“. Dėl to VM tomus saugome QCOW2 formatu XFS arba EXT4, kuris yra įdiegtas ant LVM2.

Mus taip pat verčia naudoti QCOW2 produktas, kurį naudojame orkestravimui – Apache CloudStack.

Norėdami sukurti atsarginę kopiją, padarome visą garsumo vaizdą kaip LVM2 momentinį vaizdą (taip, žinome, kad LVM2 momentinės nuotraukos yra lėtos, bet Intel P4500 mums taip pat padeda). Mes darome lvmcreate -s .. ir su pagalba dd atsarginę kopiją siunčiame į nuotolinį serverį su ZFS saugykla. Čia mes vis dar šiek tiek progresuojame - juk ZFS gali saugoti duomenis suspausta forma, o mes galime greitai juos atkurti naudodami DD arba gaukite atskirus VM tomus naudodami mount -o loop ....

Žinoma, galite pašalinti ne visą LVM2 tomo vaizdą, bet prijungti failų sistemą į RO ir nukopijuoti pačius QCOW2 vaizdus, ​​tačiau susidūrėme su tuo, kad nuo to XFS tapo bloga ir ne iš karto, o nenuspėjamai. Mums labai nepatinka, kai savaitgaliais, naktimis ar švenčių dienomis netikėtai „prilimpa“ hipervizorių šeimininkai dėl klaidų, kurios neaišku, kada jos įvyks. Todėl XFS nenaudojame momentinio vaizdo montavimo RO Norėdami išgauti tūrius, tiesiog nukopijuojame visą LVM2 tomą.

Atsarginio kopijavimo į atsarginį serverį greitį mūsų atveju lemia atsarginio serverio našumas, kuris yra apie 600-800 MB/s nesuspaudžiamiems duomenims, dar vienas ribotuvas yra 10Gbit/s kanalas, su kuriuo yra prijungtas atsarginis serveris. į klasterį.

Tokiu atveju 8 hipervizorių serverių atsarginės kopijos vienu metu įkeliamos į vieną atsarginį serverį. Taigi atsarginio serverio disko ir tinklo posistemiai, būdami lėtesni, neleidžia hipervizoriaus pagrindinių kompiuterių disko posistemiams perkrauti, nes jie tiesiog nepajėgia apdoroti, tarkime, 8 GB/sek, o tai gali lengvai atlikti hipervizoriaus prieglobos gaminti.

Aukščiau pateiktas kopijavimo procesas yra labai svarbus tolimesnei istorijai, įskaitant detales - naudojant greitą Intel P4500 diską, naudojant NFS ir tikriausiai naudojant ZFS.

Atsarginė istorija

Kiekviename hipervizoriaus mazge turime nedidelį 8 GB dydžio SWAP skaidinį, o patį hipervizoriaus mazgą „išskleidžiame“ naudodami DD iš pamatinio vaizdo. Sistemos tūriui serveriuose naudojame 2xSATA SSD RAID1 arba 2xSAS HDD RAID1 LSI arba HP aparatinės įrangos valdiklyje. Apskritai, mums visiškai nesvarbu, kas yra viduje, nes mūsų sistemos tūris veikia „beveik skaitymo“ režimu, išskyrus SWAP. O kadangi serveryje turime daug RAM ir ji yra 30-40% nemokama, apie SWAP negalvojame.

Atsarginės kopijos kūrimo procesas. Ši užduotis atrodo maždaug taip:

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

Atminkite, kad ionice -c3Tiesą sakant, šis dalykas yra visiškai nenaudingas NVMe įrenginiams, nes jiems skirtas IO planuoklis nustatytas kaip:

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

Tačiau turime nemažai senų mazgų su įprastais SSD RAID, jiems tai aktualu, todėl jie juda KAIP YRA. Apskritai tai tik įdomi kodo dalis, paaiškinanti beprasmybę ionice esant tokiai konfigūracijai.

Atkreipkite dėmesį į vėliavą iflag=direct už DD. Naudojame tiesioginį IO, aplenkdami buferio talpyklą, kad išvengtume nereikalingo IO buferių keitimo skaitant. Tačiau oflag=direct to nedarome, nes jį naudodami susidūrėme su ZFS našumo problemomis.

Šią schemą sėkmingai naudojame jau keletą metų be problemų.

Ir tada prasidėjo... Mes nustatėme, kad vieno iš mazgų atsarginė kopija nebėra, o ankstesnis veikė su didžiuliu 50 % IOWAIT. Bandydami suprasti, kodėl kopijavimas nevyksta, susidūrėme su tokiu reiškiniu:

Volume group "images" not found

Pradėjome galvoti apie „Intel P4500 atėjo galas“, tačiau prieš išjungiant serverį, kad būtų pakeistas diskas, vis tiek reikėjo padaryti atsarginę kopiją. Ištaisėme LVM2 atkurdami metaduomenis iš LVM2 atsarginės kopijos:

vgcfgrestore images

Paleidome atsarginę kopiją ir pamatėme šį aliejinį paveikslą:

Vėl buvome labai liūdni – buvo aišku, kad taip gyventi negalime, nes nukentės visi VPS, vadinasi, kentėsime ir mes. Kas atsitiko, visiškai neaišku - iostat parodė apgailėtiną IOPS ir aukščiausią IOWAIT. Nebuvo jokių kitų idėjų, išskyrus „pakeiskime NVMe“, bet įžvalga atsirado pačiu laiku.

Situacijos analizė žingsnis po žingsnio

Istorinis žurnalas. Keliomis dienomis anksčiau šiame serveryje reikėjo sukurti didelį VPS su 128 GB RAM. Atminties, regis, užtenka, bet saugumo sumetimais skyrėme dar 32 GB mainų skaidiniui. VPS buvo sukurtas, sėkmingai įvykdė savo užduotį ir incidentas buvo pamirštas, tačiau SWAP skaidinys liko.

Konfigūracijos ypatybės. Visiems debesies serveriams parametras vm.swappiness buvo nustatytas kaip numatytasis 60. O SWAP buvo sukurtas SAS HDD RAID1.

Kas atsitiko (redaktorių teigimu). Kuriant atsarginę kopiją DD sukūrė daug rašymo duomenų, kurie buvo patalpinti į RAM buferius prieš rašant į NFS. Sistemos branduolys, vadovaujamasi politika swappiness, perkeldavo daug puslapių VPS atminties į apsikeitimo sritį, kuri buvo lėtame HDD RAID1 tome. Dėl to IOWAIT labai stipriai išaugo, bet ne dėl IO NVMe, o dėl IO HDD RAID1.

Kaip buvo išspręsta problema. 32 GB apsikeitimo skaidinys buvo išjungtas. Tai užtruko 16 valandų; apie tai, kaip ir kodėl SWAP taip lėtai išsijungia, galite perskaityti atskirai. Nustatymai buvo pakeisti swappiness į vertę, lygią 5 visame debesyje.

Kaip tai galėjo neįvykti?. Pirma, jei SWAP būtų SSD RAID ar NVMe įrenginyje, o antra, jei būtų ne NVMe įrenginys, o lėtesnis įrenginys, kuris negamintų tokio kiekio duomenų – ironiška, bet problema įvyko dėl to, kad tas NVMe yra per greitas.

Po to viskas pradėjo veikti kaip anksčiau - su nuliu IOWAIT.

Šaltinis: www.habr.com