Multa libera RAM, NVMe Intel P4500 kaj ĉio estas ekstreme malrapida - la rakonto pri la malsukcesa aldono de interŝanĝa sekcio

En ĉi tiu artikolo, mi parolos pri situacio, kiu lastatempe okazis kun unu el la serviloj en nia VPS-nubo, kiu lasis min konsternita dum pluraj horoj. Mi agordas kaj solvis problemojn Linuksajn servilojn dum ĉirkaŭ 15 jaroj, sed ĉi tiu kazo tute ne taŭgas en mia praktiko - mi faris plurajn falsajn supozojn kaj iom malesperis antaŭ ol mi povis ĝuste determini la kaŭzon de la problemo kaj solvi ĝin. .

Antaŭparolo

Ni funkciigas mezgrandan nubon, kiun ni konstruas sur normaj serviloj kun la sekva agordo - 32 kernoj, 256 GB RAM kaj 4500TB PCI-E Intel P4 NVMe-disko. Ni tre ŝatas ĉi tiun agordon ĉar ĝi forigas la bezonon zorgi pri IO-superkompeto provizante la ĝustan limigon ĉe la VM-instanca tipo-nivelo. Ĉar NVMe Intel P4500 havas imponan agadon, ni povas samtempe provizi kaj plenan IOPS-provizon al maŝinoj kaj rezerva stokado al rezerva servilo kun nulo IOWAIT.

Ni estas unu el tiuj malnovaj kredantoj, kiuj ne uzas hiperkonverĝan SDN kaj aliajn elegantajn, modajn, junajn aferojn por stoki VM-volumojn, kredante, ke ju pli simpla la sistemo, des pli facile estas solvi ĝin en la kondiĉoj de "la ĉefa guruo foriris. al la montoj.” Kiel rezulto, ni stokas VM-volumojn en QCOW2-formato en XFS aŭ EXT4, kiu estas deplojita supre de LVM2.

Ni ankaŭ estas devigitaj uzi QCOW2 per la produkto, kiun ni uzas por instrumentado - Apache CloudStack.

Por fari sekurkopion, ni prenas plenan bildon de la volumo kiel LVM2 momentfoto (jes, ni scias, ke LVM2 momentfotoj estas malrapidaj, sed la Intel P4500 helpas nin ankaŭ ĉi tie). Ni faras lvmcreate -s .. kaj kun la helpo dd ni sendas la rezervan kopion al fora servilo kun ZFS-stokado. Ĉi tie ni ankoraŭ estas iomete progresemaj - finfine, ZFS povas stoki datumojn en kunpremita formo, kaj ni povas rapide restarigi ĝin uzante DD aŭ akiri individuajn VM-volumojn uzante mount -o loop ....

Vi povas, kompreneble, forigi ne la plenan bildon de la LVM2-volumo, sed munti la dosiersistemon en la RO kaj kopiu la QCOW2-bildojn mem, tamen, ni alfrontis la fakton, ke XFS iĝis malbona pro tio, kaj ne tuj, sed en neantaŭvidebla maniero. Ni vere ne ŝatas, kiam hiperviziero gastigas "stick" subite semajnfine, nokte aŭ feriaj pro eraroj, kiuj ne klaras, kiam ili okazos. Tial, por XFS ni ne uzas momentfotomuntadon enen RO por ĉerpi volumojn, ni simple kopias la tutan LVM2-volumon.

La rapideco de sekurkopio al la rezerva servilo estas determinita en nia kazo de la agado de la rezerva servilo, kiu estas ĉirkaŭ 600-800 MB/s por nekunpremeblaj datumoj; plia limigilo estas la 10Gbit/s kanalo kun kiu la rezerva servilo estas konektita. al la areto.

En ĉi tiu kazo, rezervaj kopioj de 8 hiperviziaj serviloj estas samtempe alŝutitaj al unu rezerva servilo. Tiel, la diskaj kaj retaj subsistemoj de la rezerva servilo, estante pli malrapidaj, ne ebligas al la disksubsistemoj de la hiperviziaj gastigantoj troŝarĝi, ĉar ili simple ne kapablas prilabori, ekzemple, 8 GB/sec, kiujn la hipervizaraj gastigantoj povas facile. produkti.

La supra kopia procezo estas tre grava por la plua rakonto, inkluzive de la detaloj - uzante rapidan Intel P4500-diskon, uzante NFS kaj, verŝajne, uzante ZFS.

Rezerva rakonto

Sur ĉiu hipervizia nodo ni havas malgrandan SWAP-sekcion de 8 GB en grandeco, kaj ni "elvolvas" la hiperviziran nodon mem uzante DD de la referenca bildo. Por la sistema volumo sur serviloj, ni uzas 2xSATA SSD RAID1 aŭ 2xSAS HDD RAID1 sur LSI aŭ HP aparataro-regilo. Ĝenerale, ni tute ne zorgas pri tio, kio estas ene, ĉar nia sistema volumo funkcias en "preskaŭ nurlegebla" reĝimo, krom SWAP. Kaj ĉar ni havas multe da RAM sur la servilo kaj ĝi estas 30-40% senpaga, ni ne pensas pri SWAP.

Rezerva procezo. Ĉi tiu tasko aspektas kiel ĉi tio:

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

atentu ionice -c3, fakte, ĉi tiu afero estas tute senutila por NVMe-aparatoj, ĉar la IO-planilo por ili estas agordita kiel:

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

Tamen ni havas kelkajn heredaĵajn nodojn kun konvenciaj SSD-RAIDoj, por ili tio gravas, do ili moviĝas. KIAL ESTAS. Ĝenerale, ĉi tio estas nur interesa kodo, kiu klarigas la vanecon ionice en kazo de tia agordo.

Atentu la flagon iflag=direct por DD. Ni uzas rektan IO preterpasante la bufrokaŝmemoron por eviti nenecesan anstataŭigon de IO-bufroj dum legado. Tamen, oflag=direct ni ne faras ĉar ni renkontis ZFS-efikecproblemojn kiam ni uzas ĝin.

Ni uzas ĉi tiun skemon sukcese dum pluraj jaroj sen problemoj.

Kaj tiam ĝi komenciĝis... Ni malkovris, ke unu el la nodoj ne plu estis subtenita, kaj la antaŭa funkciis kun monstra IOWAIT de 50%. Provante kompreni kial kopiado ne okazas, ni renkontis la jenan fenomenon:

Volume group "images" not found

Ni komencis pensi pri "la fino venis por la Intel P4500", tamen antaŭ ol malŝalti la servilon por anstataŭigi la diskon, ankoraŭ necesis fari sekurkopion. Ni riparis LVM2 per restarigo de metadatenoj de LVM2-rezervo:

vgcfgrestore images

Ni lanĉis sekurkopion kaj vidis ĉi tiun oleopentraĵon:

Denove ni estis tre malĝojaj - estis klare, ke ni ne povus vivi tiel, ĉar ĉiuj VPS-oj suferus, kio signifas, ke ankaŭ ni suferus. Kio okazis estas tute neklara - iostat montris kompatindan IOPS kaj la plej altan IOWAIT. Ne estis ideoj krom "ni anstataŭigu NVMe", sed kompreno okazis ĝustatempe.

Analizo de la situacio paŝo post paŝo

Historia revuo. Kelkajn tagojn antaŭe, sur ĉi tiu servilo necesis krei grandan VPS kun 128 GB-RAM. Ŝajnis sufiĉe da memoro, sed por esti sekura flanko, ni asignis pliajn 32 GB por la interŝanĝa sekcio. La VPS estis kreita, sukcese kompletigis sian taskon kaj la okazaĵo estis forgesita, sed la SWAP-diskodo restis.

Agordaj Trajtoj. Por ĉiuj nubaj serviloj la parametro vm.swappiness estis defaŭlta 60. Kaj SWAP estis kreita sur SAS HDD RAID1.

Kio okazis (laŭ la redaktoroj). Dum sekurkopio DD produktis multajn skribajn datumojn, kiuj estis metitaj en RAM-bufrojn antaŭ skribi al NFS. Sistemkerno, gvidita de politiko swappiness, movis multajn paĝojn de VPS-memoro al la interŝanĝa areo, kiu situis sur malrapida HDD RAID1-volumo. Ĉi tio kondukis al IOWAIT kreskanta tre forte, sed ne pro IO NVMe, sed pro IO HDD RAID1.

Kiel la problemo estis solvita. La interŝanĝa sekcio de 32GB estis malŝaltita. Ĉi tio daŭris 16 horojn; vi povas legi aparte pri kiel kaj kial SWAP malŝaltas tiel malrapide. Agordoj estis ŝanĝitaj swappiness al valoro egala al 5 tra la tuta nubo.

Kiel ĉi tio ne povus okazi?. Unue, se SWAP estus sur SSD RAID aŭ NVMe-aparato, kaj due, se ne ekzistus NVMe-aparato, sed pli malrapida aparato, kiu ne produktus tian volumon da datumoj - ironie, la problemo okazis ĉar tiu NVMe estas tro rapida.

Post tio, ĉio komencis funkcii kiel antaŭe - kun nulo IOWAIT.

fonto: www.habr.com