Daghang libre nga RAM, NVMe Intel P4500 ug ang tanan hinay kaayo - ang istorya sa dili malampuson nga pagdugang sa usa ka swap partition

Niini nga artikulo, maghisgot ako bahin sa usa ka kahimtang nga bag-o lang nahitabo sa usa sa mga server sa among VPS nga panganod, nga nakapahadlok kanako sa daghang oras. Gi-configure ug gi-troubleshoot nako ang mga server sa Linux sa mga 15 ka tuig, apan kini nga kaso wala gyud mohaum sa akong praktis - Naghimo ako daghang sayup nga mga pangagpas ug medyo desperado sa wala pa nako matino ang hinungdan sa problema ug masulbad kini. .

Pasiuna

Naglihok kami sa usa ka medium-sized nga panganod, nga among gitukod sa standard nga mga server nga adunay mosunod nga configuration - 32 cores, 256 GB RAM ug usa ka 4500TB PCI-E Intel P4 NVMe drive. Ganahan kaayo kami niini nga configuration tungod kay kini nagwagtang sa panginahanglan nga mabalaka mahitungod sa IO overhead pinaagi sa paghatag sa husto nga pagdili sa VM instance type level. Tungod kay ang NVMe Intel P4500 adunay impresibo nga pasundayag, mahimo namon nga dungan nga mahatagan ang parehas nga tibuuk nga probisyon sa IOPS sa mga makina ug pagtipig sa backup sa usa ka backup nga server nga adunay zero IOWAIT.

Usa kami sa mga tigulang nga magtutuo nga wala mogamit sa hyperconverged SDN ug uban pang mga istilo, uso, mga butang sa kabatan-onan aron tipigan ang mga volume sa VM, nga nagtuo nga ang labi ka yano nga sistema, labi ka dali nga masulbad kini sa mga kondisyon nga "nawala na ang panguna nga magtutudlo. ngadto sa kabukiran.” Ingon usa ka sangputanan, among gitipigan ang mga volume sa VM sa format nga QCOW2 sa XFS o EXT4, nga gi-deploy sa ibabaw sa LVM2.

Napugos usab kami sa paggamit sa QCOW2 sa produkto nga among gigamit alang sa orkestrasyon - Apache CloudStack.

Aron mahimo ang usa ka backup, gikuha namon ang usa ka tibuuk nga imahe sa volume ingon usa ka snapshot sa LVM2 (oo, nahibal-an namon nga ang mga snapshot sa LVM2 hinay, apan ang Intel P4500 nagtabang usab kanamo dinhi). Gibuhat namo lvmcreate -s .. ug uban sa tabang dd gipadala namo ang backup nga kopya sa usa ka hilit nga server nga adunay ZFS storage. Dinhi kita gamay pa nga progresibo - bisan pa, ang ZFS makatipig sa datos sa compressed nga porma, ug mahimo natong ibalik kini dayon gamit ang DD o pagkuha sa indibidwal nga mga volume sa VM gamit mount -o loop ....

Mahimo nimo, siyempre, dili tangtangon ang tibuuk nga imahe sa volume sa LVM2, apan i-mount ang file system sa RO ug kopyaha ang mga imahe sa QCOW2 sa ilang kaugalingon, bisan pa, nag-atubang kami sa kamatuoran nga ang XFS nahimong daotan gikan niini, ug dili dayon, apan sa dili matag-an nga paagi. Dili gyud kami ganahan kung ang hypervisor host kalit nga "stick" sa katapusan sa semana, sa gabii o sa mga holiday tungod sa mga sayup nga dili klaro kung kanus-a kini mahitabo. Busa, alang sa XFS wala kami mogamit sa snapshot mounting in RO aron makuha ang mga volume, kopyahon lang namo ang tibuok volume sa LVM2.

Ang katulin sa pag-backup sa backup nga server gitino sa among kaso pinaagi sa paghimo sa backup nga server, nga mga 600-800 MB / s alang sa dili ma-compress nga data; ang dugang nga limiter mao ang 10Gbit / s nga channel diin ang backup server konektado ngadto sa cluster.

Sa kini nga kaso, ang mga backup nga kopya sa 8 nga hypervisor server dungan nga gi-upload sa usa ka backup nga server. Busa, ang disk ug network subsystems sa backup server, nga mas hinay, dili motugot sa disk subsystems sa hypervisor hosts nga mag-overload, tungod kay sila dili makahimo sa pagproseso, ingon, 8 GB/sec, nga ang hypervisor hosts dali ra. makapatungha.

Ang proseso sa pagkopya sa ibabaw hinungdanon kaayo alang sa dugang nga istorya, lakip ang mga detalye - gamit ang paspas nga Intel P4500 drive, gamit ang NFS ug, tingali, gamit ang ZFS.

I-backup nga istorya

Sa matag hypervisor node kami adunay gamay nga SWAP partition nga 8 GB ang gidak-on, ug among "i-roll out" ang hypervisor node mismo gamit ang DD gikan sa reference nga larawan. Alang sa gidaghanon sa sistema sa mga server, gigamit namo ang 2xSATA SSD RAID1 o 2xSAS HDD RAID1 sa LSI o HP hardware controller. Sa kinatibuk-an, wala namo igsapayan kung unsa ang naa sa sulod, tungod kay ang gidaghanon sa among sistema naglihok sa "halos readonly" nga mode, gawas sa SWAP. Ug tungod kay kami adunay daghang RAM sa server ug kini 30-40% nga libre, wala kami maghunahuna bahin sa SWAP.

Proseso sa pag-backup. Kini nga buluhaton ingon niini:

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

Pagtagad ionice -c3, sa tinuud, kini nga butang hingpit nga wala’y kapuslanan alang sa mga aparato sa NVMe, tungod kay ang IO scheduler alang kanila gitakda ingon:

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

Bisan pa, kami adunay daghang mga kabilin nga node nga adunay naandan nga SSD RAID, alang kanila kini may kalabutan, mao nga sila naglihok. AS IS. Sa kinatibuk-an, kini usa lamang ka makapaikag nga piraso sa code nga nagpatin-aw sa pagkawalay kapuslanan ionice sa kaso sa ingon nga configuration.

Hatagi'g pagtagad ang bandila iflag=direct alang sa DD. Gigamit namon ang direkta nga IO nga nag-bypass sa buffer cache aron malikayan ang wala kinahanglana nga pag-ilis sa mga buffer sa IO kung nagbasa. Apan, oflag=direct dili tungod kay nasugatan namo ang mga isyu sa performance sa ZFS sa paggamit niini.

Nagamit namon kini nga laraw nga malampuson sa daghang mga tuig nga wala’y mga problema.

Ug unya nagsugod kini... Among nadiskobrehan nga ang usa sa mga node wala na gi-back up, ug ang nauna nagdagan nga adunay usa ka makalilisang nga IOWAIT nga 50%. Kung gisulayan nga masabtan kung nganong wala mahitabo ang pagkopya, nasugatan namo ang mosunod nga panghitabo:

Volume group "images" not found

Nagsugod kami sa paghunahuna bahin sa "ang katapusan miabot na alang sa Intel P4500," bisan pa, sa wala pa i-off ang server aron mapulihan ang drive, kinahanglan pa nga maghimo usa ka backup. Giayo namo ang LVM2 pinaagi sa pagpasig-uli sa metadata gikan sa backup sa LVM2:

vgcfgrestore images

Naglunsad kami og backup ug nakita kining oil painting:

Sa makausa pa kami nasubo kaayo - klaro nga dili kami mabuhi nga ingon niini, tungod kay ang tanan nga mga VPS mag-antus, nga nagpasabut nga kami usab mag-antus. Unsa ang nahitabo dili klaro - iostat nagpakita sa makaluluoy nga IOPS ug ang pinakataas nga IOWAIT. Wala'y mga ideya gawas sa "ilisan nato ang NVMe," apan usa ka pagsabot nahitabo sa tukmang panahon.

Pag-analisar sa sitwasyon sa lakang

Makasaysayan nga magasin. Pipila ka adlaw sa sayo pa, sa kini nga server kinahanglan nga maghimo usa ka dako nga VPS nga adunay 128 GB RAM. Daw adunay igo nga panumduman, apan aron anaa sa luwas nga bahin, among gigahin ang laing 32 GB alang sa swap partition. Ang VPS gimugna, malampuson nga nahuman ang buluhaton niini ug ang insidente nakalimtan, apan ang SWAP partition nagpabilin.

Mga Feature sa Pag-configure. Para sa tanang cloud server ang parameter vm.swappiness gibutang sa default 60. Ug ang SWAP gihimo sa SAS HDD RAID1.

Unsa ang nahitabo (sumala sa mga editor). Sa dihang nag-back up DD nagpatunghag daghang data sa pagsulat, nga gibutang sa mga buffer sa RAM sa wala pa magsulat sa NFS. Kinauyokan sa sistema, gigiyahan sa palisiya swappiness, nagbalhin sa daghang mga panid sa memorya sa VPS ngadto sa swap area, nga nahimutang sa hinay nga gidaghanon sa HDD RAID1. Kini misangpot sa IOWAIT nga mitubo nga kusog kaayo, apan dili tungod sa IO NVMe, apan tungod sa IO HDD RAID1.

Sa unsang paagi nasulbad ang problema. Ang 32GB swap partition gi-disable. Nagkinahanglan kini og 16 ka oras; mahimo nimong basahon ang gilain bahin sa kung giunsa ug ngano nga hinay kaayo nga nag-off ang SWAP. Giusab ang mga setting swappiness sa usa ka bili nga katumbas sa 5 sa tibuok panganod.

Sa unsang paagi dili kini mahitabo?. Una, kung ang SWAP naa sa usa ka SSD RAID o NVMe nga aparato, ug ikaduha, kung wala’y aparato nga NVMe, apan usa ka hinay nga aparato nga dili makagama sa ingon nga gidaghanon sa datos - sa tinuud, ang problema nahitabo tungod kay ang NVMe kusog kaayo.

Pagkahuman niana, ang tanan nagsugod sa pagtrabaho sama kaniadto - nga adunay zero IOWAIT.

Source: www.habr.com