Sa artikulong ito, magsasalita ako tungkol sa isang sitwasyon na naganap kamakailan sa isa sa mga server sa aming VPS cloud, na nag-iwan sa akin na natigilan ng ilang oras. Nag-configure at nag-troubleshoot ako ng mga server ng Linux sa loob ng halos 15 taon, ngunit ang kasong ito ay hindi umaangkop sa aking pagsasanay - Gumawa ako ng maraming maling pagpapalagay at medyo desperado bago ko matukoy nang tama ang sanhi ng problema at malutas ito .
Paunang salita
Nagpapatakbo kami ng isang medium-sized na cloud, na binuo namin sa mga karaniwang server na may sumusunod na configuration - 32 core, 256 GB RAM at isang 4500TB PCI-E Intel P4 NVMe drive. Talagang gusto namin ang configuration na ito dahil inaalis nito ang pangangailangang mag-alala tungkol sa overhead ng IO sa pamamagitan ng pagbibigay ng tamang paghihigpit sa antas ng uri ng instance ng VM. Dahil ang NVMe Intel ay may kahanga-hangang pagganap, maaari naming sabay na ibigay ang parehong buong IOPS provisioning sa mga makina at backup na storage sa isang backup na server na may zero IOWAIT.
Kami ay isa sa mga lumang mananampalataya na hindi gumagamit ng hyperconverged SDN at iba pang naka-istilong, sunod sa moda, mga bagay ng kabataan upang mag-imbak ng mga volume ng VM, na naniniwala na ang mas simple ang sistema, mas madaling i-troubleshoot ito sa mga kondisyon ng "ang pangunahing guro ay nawala sa mga bundok.β Bilang resulta, nag-iimbak kami ng mga volume ng VM sa QCOW2 na format sa XFS o EXT4, na naka-deploy sa itaas ng LVM2.
Napipilitan din kaming gamitin ang QCOW2 ng produktong ginagamit namin para sa orkestrasyon - Apache CloudStack.
Upang magsagawa ng backup, kumuha kami ng buong larawan ng volume bilang isang snapshot ng LVM2 (oo, alam namin na mabagal ang mga snapshot ng LVM2, ngunit tinutulungan din kami ng Intel P4500 dito). ginagawa namin lvmcreate -s .. at sa tulong dd ipinapadala namin ang backup na kopya sa isang malayong server na may imbakan ng ZFS. Dito pa rin tayo bahagyang progresibo - pagkatapos ng lahat, ang ZFS ay maaaring mag-imbak ng data sa naka-compress na anyo, at mabilis nating maibabalik ito gamit ang DD o kumuha ng mga indibidwal na volume ng VM gamit mount -o loop ....
Maaari mong, siyempre, alisin hindi ang buong imahe ng dami ng LVM2, ngunit i-mount ang file system sa
ROat kopyahin ang mga imahe ng QCOW2 sa kanilang sarili, gayunpaman, kami ay nahaharap sa katotohanan na ang XFS ay naging masama mula dito, at hindi kaagad, ngunit sa isang hindi mahuhulaan na paraan. Talagang hindi namin gusto kapag ang hypervisor ay nagho-host ng "stick" nang biglaan sa katapusan ng linggo, sa gabi o sa mga holiday dahil sa mga error na hindi malinaw kung kailan ito mangyayari. Samakatuwid, para sa XFS hindi kami gumagamit ng snapshot mounting inROpara mag-extract ng mga volume, kopyahin lang namin ang buong volume ng LVM2.
Ang bilis ng pag-backup sa backup na server ay tinutukoy sa aming kaso ng pagganap ng backup na server, na humigit-kumulang 600-800 MB/s para sa hindi mapipigil na data; ang karagdagang limiter ay ang 10Gbit/s channel kung saan nakakonekta ang backup server sa kumpol.
Sa kasong ito, ang mga backup na kopya ng 8 hypervisor server ay sabay-sabay na ina-upload sa isang backup na server. Kaya, ang mga subsystem ng disk at network ng backup na server, na mas mabagal, ay hindi pinapayagan ang mga subsystem ng disk ng mga host ng hypervisor na mag-overload, dahil hindi nila kayang iproseso, sabihin, 8 GB/sec, na madaling magagawa ng mga host ng hypervisor. gumawa.
Ang proseso ng pagkopya sa itaas ay napakahalaga para sa karagdagang kuwento, kabilang ang mga detalye - gamit ang isang mabilis na Intel P4500 drive, gamit ang NFS at, malamang, gamit ang ZFS.
Backup na kwento
Sa bawat hypervisor node mayroon kaming maliit na SWAP partition na 8 GB ang laki, at "ilalabas" namin ang hypervisor node mismo gamit ang DD mula sa reference na larawan. Para sa dami ng system sa mga server, gumagamit kami ng 2xSATA SSD RAID1 o 2xSAS HDD RAID1 sa isang LSI o HP hardware controller. Sa pangkalahatan, wala kaming pakialam kung ano ang nasa loob, dahil ang dami ng aming system ay gumagana sa "halos readonly" na mode, maliban sa SWAP. At dahil marami kaming RAM sa server at ito ay 30-40% libre, hindi namin iniisip ang tungkol sa SWAP.
Proseso ng pag-backup. Ang gawaing ito ay mukhang ganito:
#!/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-snapTandaan ang ionice -c3, sa katunayan, ang bagay na ito ay ganap na walang silbi para sa mga NVMe device, dahil ang IO scheduler para sa kanila ay nakatakda bilang:
cat /sys/block/nvme0n1/queue/scheduler
[none] Gayunpaman, mayroon kaming ilang mga legacy na node na may mga kumbensyonal na SSD RAID, para sa kanila ito ay may kaugnayan, kaya sila ay gumagalaw AS IS. Sa pangkalahatan, ito ay isa lamang kawili-wiling piraso ng code na nagpapaliwanag ng kawalang-saysay ionice sa kaso ng naturang pagsasaayos.
Bigyang-pansin ang bandila iflag=direct para sa DD. Gumagamit kami ng direktang IO sa pag-bypass sa buffer cache upang maiwasan ang hindi kinakailangang pagpapalit ng mga buffer ng IO kapag nagbabasa. gayunpaman, oflag=direct hindi namin ginagawa dahil nakatagpo kami ng mga isyu sa pagganap ng ZFS kapag ginagamit ito.
Matagumpay naming ginagamit ang scheme na ito sa loob ng ilang taon nang walang problema.
At pagkatapos ay nagsimula ito... Natuklasan namin na ang isa sa mga node ay hindi na naka-back up, at ang nauna ay tumatakbo na may napakalaking IOWAIT na 50%. Kapag sinusubukang maunawaan kung bakit hindi nangyayari ang pagkopya, nakatagpo kami ng sumusunod na kababalaghan:
Volume group "images" not foundNagsimula kaming mag-isip tungkol sa "dumating na ang katapusan para sa Intel P4500," gayunpaman, bago i-off ang server upang palitan ang drive, kailangan pa ring magsagawa ng backup. Inayos namin ang LVM2 sa pamamagitan ng pagpapanumbalik ng metadata mula sa isang backup ng LVM2:
vgcfgrestore imagesNaglunsad kami ng backup at nakita ang oil painting na ito:
Muli kaming nalungkot - malinaw na hindi kami mabubuhay ng ganito, dahil lahat ng VPS ay magdurusa, na nangangahulugang magdurusa din kami. Ang nangyari ay ganap na hindi malinaw - iostat nagpakita ng kaawa-awang IOPS at ang pinakamataas na IOWAIT. Walang mga ideya maliban sa "palitan natin ang NVMe," ngunit isang insight ang nangyari sa tamang oras.
Pagsusuri ng sitwasyon nang hakbang-hakbang
Makasaysayang magasin. Ilang araw mas maaga, sa server na ito ay kinakailangan upang lumikha ng isang malaking VPS na may 128 GB RAM. Tila may sapat na memorya, ngunit upang maging ligtas, naglaan kami ng isa pang 32 GB para sa swap partition. Ang VPS ay nilikha, matagumpay na natapos ang gawain nito at ang insidente ay nakalimutan, ngunit ang SWAP partition ay nanatili.
Mga Tampok ng Configuration. Para sa lahat ng cloud server ang parameter vm.swappiness ay itinakda sa default 60. At ang SWAP ay ginawa sa SAS HDD RAID1.
Ano ang nangyari (ayon sa mga editor). Kapag nagba-back up DD gumawa ng maraming write data, na inilagay sa mga buffer ng RAM bago sumulat sa NFS. System core, ginagabayan ng patakaran swappiness, ay naglilipat ng maraming page ng VPS memory sa swap area, na matatagpuan sa mabagal na volume ng HDD RAID1. Ito ay humantong sa IOWAIT na lumago nang napakalakas, ngunit hindi dahil sa IO NVMe, ngunit dahil sa IO HDD RAID1.
Paano nalutas ang problema. Ang 32GB swap partition ay hindi pinagana. Tumagal ito ng 16 na oras; maaari mong basahin nang hiwalay ang tungkol sa kung paano at bakit napakabagal na nag-off ang SWAP. Nabago ang mga setting swappiness sa isang halaga na katumbas ng 5 sa buong ulap.
Paanong hindi ito mangyayari?. Una, kung ang SWAP ay nasa isang SSD RAID o NVMe device, at pangalawa, kung walang NVMe device, ngunit isang mas mabagal na device na hindi makagawa ng ganoong dami ng data - balintuna, nangyari ang problema dahil masyadong mabilis ang NVMe na iyon.
Pagkatapos nito, nagsimulang gumana ang lahat tulad ng dati - na may zero IOWAIT.
Pinagmulan: www.habr.com