Doako RAM asko, NVMe Intel P4500 eta dena oso motela da - truke-partizioa arrakastarik gabe gehitzearen istorioa

Artikulu honetan, duela gutxi gure VPS hodeiko zerbitzarietako batekin gertatutako egoera bati buruz hitz egingo dut, hainbat orduz harrituta utzi ninduen. 15 bat urte daramatzat Linux zerbitzariak konfiguratzen eta konpontzen, baina kasu hau ez da batere sartzen nire praktikan - hainbat hipotesi faltsu egin nituen eta apur bat etsi egin nintzen arazoaren kausa behar bezala zehaztu eta konpontzeko gai izan baino lehen. .

hitzaurrean

Tamaina ertaineko hodei bat lantzen dugu, zerbitzari estandarretan eraikitzen duguna honako konfigurazioarekin: 32 nukleo, 256 GB RAM eta 4500TB PCI-E Intel P4 NVMe unitatea. Asko gustatzen zaigu konfigurazio hau, IO-ko gastuei buruz kezkatu beharra ezabatzen duelako, VM instantzia mota mailan murrizketa zuzena eskainiz. NVMe Intel delako P4500 errendimendu ikusgarria du, aldi berean eskain ditzakegu IOPS horniketa osoa makinei eta babeskopia biltegiratzea IOWAIT zero duen babeskopia zerbitzari bati.

SDN hiperkonbergeatua eta beste gauza dotore, modan eta gazteak erabiltzen ez dituen fededun zahar horietako bat gara VM bolumenak gordetzeko, sistema zenbat eta sinpleagoa izan, orduan eta errazago konpontzea "guru nagusia joan da" baldintzetan. mendira». Ondorioz, VM bolumenak QCOW2 formatuan gordetzen ditugu XFS edo EXT4-n, LVM2-ren gainean zabaltzen dena.

QCOW2 erabiltzera behartuta gaude orkestraziorako erabiltzen dugun produktuak - Apache CloudStack.

Babeskopia bat egiteko, bolumenaren irudi osoa hartzen dugu LVM2 argazki gisa (bai, badakigu LVM2 argazkiak motelak direla, baina Intel P4500-k hemen ere laguntzen digu). Egiten dugu lvmcreate -s .. eta laguntzarekin dd babeskopia ZFS biltegia duen urruneko zerbitzari batera bidaltzen dugu. Hemen oraindik pixka bat aurrerakoiak gara - azken finean, ZFS-k datuak forma konprimituan gorde ditzake eta azkar berreskura ditzakegu erabiliz. DD edo lortu VM bolumen indibidualak erabiliz mount -o loop ....

Jakina, ez dezakezu LVM2 bolumenaren irudi osoa kendu, baina fitxategi-sistema muntatu dezakezu RO eta kopiatu QCOW2 irudiak beraiek, ordea, XFS gaiztotu egin zela aurre egin genuen, eta ez berehala, ezusteko moduan baizik. Benetan ez zaigu gustatzen hipervisorea ostalari bat-batean "makilatzen" denean asteburuetan, gauez edo jaiegunetan noiz gertatuko diren argi ez duten akatsengatik. Beraz, XFSrako ez dugu argazkien muntaketa erabiltzen RO bolumenak ateratzeko, LVM2 bolumen osoa kopiatu besterik ez dugu egiten.

Babeskopia-zerbitzariaren segurtasun-kopia egiteko abiadura gure kasuan babeskopia-zerbitzariaren errendimenduaren arabera zehazten da, hau da, 600-800 MB/s inguruko datu konprimaezinetarako; beste mugatzaile bat babeskopia zerbitzaria konektatuta dagoen 10 Gbit/s kanala da. klusterera.

Kasu honetan, 8 hipervisor zerbitzariren babeskopiak aldi berean kargatzen dira babeskopia zerbitzari batera. Beraz, babeskopia zerbitzariaren disko eta sare azpisistemek, motelagoak izanik, ez dute hipervisorearen ostalarien disko azpisistemei gainkargatzen uzten, ezin baitute, esate baterako, 8 GB/seg prozesatu, hipervisoreko ostalariek erraz egin dezaketena. ekoitzi.

Goiko kopia-prozesua oso garrantzitsua da istorio gehiagorako, xehetasunak barne: Intel P4500 disko azkarra erabiliz, NFS erabiliz eta, ziurrenik, ZFS erabiliz.

Backup istorioa

Hipervisor-nodo bakoitzean 8 GB-ko tamainako SWAP partizio txiki bat dugu, eta hipervisor-nodoa bera "zabaltzen" dugu. DD erreferentziako iruditik. Zerbitzarietako sistemaren bolumenerako, 2xSATA SSD RAID1 edo 2xSAS HDD RAID1 erabiltzen dugu LSI edo HP hardware kontrolagailu batean. Oro har, ez zaigu batere axola zer dagoen barruan, gure sistemaren bolumenak "ia irakurtzeko soilik" moduan funtzionatzen baitu, SWAP izan ezik. Eta zerbitzarian RAM asko daukagunez eta %30-40 doakoa denez, ez dugu SWAP-ean pentsatzen.

Backup-prozesua. Zeregin honek honelako itxura du:

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

Kontuan izan ionice -c3Izan ere, gauza hau guztiz alferrikakoa da NVMe gailuetarako, haientzako IO-en programatzailea honela ezartzen baita:

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

Hala eta guztiz ere, SSD RAID konbentzionalak dituzten oinordeko nodo batzuk ditugu, hauentzat garrantzitsua da, beraz, mugitzen ari dira. DAGOEN BEZALA. Orokorrean, hutsaltasuna azaltzen duen kode interesgarri bat besterik ez da ionice konfigurazio hori izanez gero.

Erreparatu banderari iflag=direct egiteko DD. Bufferren cachea saihestuz zuzeneko IO erabiltzen dugu irakurtzerakoan IO bufferrak alferrikako ordezkapena saihesteko. Hala ere, oflag=direct ez dugu erabiltzen ZFS errendimendu-arazoak aurkitu ditugulako.

Hainbat urte daramatzagu eskema hau arrakastaz erabiltzen arazorik gabe.

Eta orduan hasi zen... Deskubritu genuen nodoetako batek ez zuela babeskopiarik egiten, eta aurrekoa %50eko IOWAIT ikaragarri batekin exekutatzen ari zela. Kopiatzea zergatik ez den gertatzen ulertzen saiatzean, honako fenomeno hau topatu dugu:

Volume group "images" not found

"Intel P4500-rako amaiera iritsi da" pentsatzen hasi ginen, hala ere, zerbitzaria desaktibatu aurretik, diskoa ordezkatzeko, beharrezkoa zen oraindik babeskopia bat egitea. LVM2 konpondu dugu LVM2 babeskopia batetik metadatuak berreskuratuz:

vgcfgrestore images

Babeskopia bat abiarazi genuen eta olio-pintura hau ikusi genuen:

Berriz ere oso triste geunden - argi zegoen ezin ginela horrela bizi, VPS guztiek sufrituko zutelako, horrek esan nahi du guk ere sufrituko genuela. Zer gertatu zen guztiz ez dago argi iostat IOPS penagarriak eta IOWAIT altuena erakutsi zituen. Ez zegoen "ordezka dezagun NVMe" beste ideiarik, baina garaiz gertatu zen ikuspegi bat.

Egoeraren analisia urratsez urrats

Aldizkari historikoa. Egun batzuk lehenago, zerbitzari honetan VPS handi bat sortzea beharrezkoa zen 128 GB RAM-ekin. Memoria nahikoa zegoela zirudien, baina alde seguruan egoteko, beste 32 GB esleitu genituen truke-partiziorako. VPS sortu zen, arrakastaz bete zuen bere zeregina eta gertakaria ahaztu zen, baina SWAP partizioa mantendu zen.

Konfigurazio Ezaugarriak. Для всех серверов облака параметр vm.swappiness lehenetsi zen 60. Eta SWAP SAS HDD RAID1-en sortu zen.

Zer gertatu zen (editoreen arabera). Babeskopia egitean DD idazketa-datu asko sortu zituen, RAM bufferetan jartzen zirenak NFSra idatzi aurretik. Sistemaren muina, politikak gidatuta swappiness, VPS memoriaren orrialde asko mugitzen ari zen truke eremura, HDD RAID1 bolumen motel batean kokatuta zegoena. Horrek IOWAIT oso indartsu haztea ekarri zuen, baina ez IO NVMe-ri esker, IO HDD RAID1-ri esker baizik.

Arazoa nola konpondu zen. 32GB trukatzeko partizioa desgaitu egin da. Honek 16 ordu behar izan ditu; bereizita irakur dezakezu SWAP hain poliki nola eta zergatik desaktibatzen den. Ezarpenak aldatu dira swappiness balio berdin bati 5 hodei osoan.

Nola liteke hau ez gertatzea?. Lehenik eta behin, SWAP SSD RAID edo NVMe gailu batean egongo balitz, eta bigarrenik, NVMe gailurik ez balego, baina datu-bolumen hori sortuko ez zuen gailu motelagoa izango balitz - ironikoki, arazoa NVMe hori azkarregia delako gertatu da.

Horren ostean, dena lehen bezala funtzionatzen hasi zen - IOWAIT zerorekin.

Iturria: www.habr.com