Vill gratis RAM, NVMe Intel P4500 an alles ass extrem lues - d'Geschicht vun der net erfollegräicher Zousatz vun enger Swap-Partition

An dësem Artikel wäert ech iwwer eng Situatioun schwätzen, déi viru kuerzem mat engem vun de Serveren an eiser VPS-Wollek geschitt ass, déi mech e puer Stonnen stousse léisst. Ech hunn Linux Serveren fir ongeféier 15 Joer konfiguréiert a Probleemer geléist, awer dëse Fall passt guer net a meng Praxis - ech hunn e puer falsch Viraussetzungen gemaach a sinn e bësse verzweifelt ier ech d'Ursaach vum Problem richteg bestëmmen an et léisen .

Präambel

Mir bedreiwen eng mëttelgrouss Wollek, déi mir op Standard Server mat der folgender Konfiguratioun bauen - 32 Kären, 256 GB RAM an e 4500TB PCI-E Intel P4 NVMe Drive. Mir hunn dës Konfiguratioun wierklech gär well et d'Noutwendegkeet eliminéiert fir sech iwwer IO Overhead ze këmmeren andeems se déi korrekt Restriktioun um VM Instanz Typ Niveau ubidden. Well NVMe Intel P4500 beandrockend Leeschtung huet, kënne mir gläichzäiteg souwuel voll IOPS Bestëmmung fir Maschinnen an Backupsatellit Stockage zu engem Backupsatellit Server mat null IOWAIT.

Mir sinn ee vun deenen ale Gleeweger, déi net hyperkonvergéiert SDN an aner stilvoll, fashionable, Jugendsaachen benotzen fir VM Bänn ze späicheren, ze gleewen datt de System méi einfach ass, wat et méi einfach ass et an de Bedéngungen ze léisen "den Haaptguru ass fort. an d'Bierger." Als Resultat späichere mir VM Bänn am QCOW2 Format an XFS oder EXT4, déi uewen op LVM2 ofgebaut gëtt.

Mir sinn och gezwongen QCOW2 ze benotzen duerch de Produit mir fir Orchestratioun benotzen - Apache CloudStack.

Fir e Backup ze maachen, huelen mir e vollt Bild vum Volume als LVM2 Snapshot (jo, mir wëssen datt LVM2 Snapshots lues sinn, awer den Intel P4500 hëlleft eis och hei). Mir maachen lvmcreate -s .. a mat der Hëllef dd mir schécken der Backupsatellit Kopie op engem Remote Server mat ZFS Stockage. Hei si mir nach ëmmer liicht progressiv - schliisslech kann ZFS Daten a kompriméierter Form späicheren, a mir kënne se séier restauréieren DD oder kréien eenzel VM Bänn benotzt mount -o loop ....

Dir kënnt selbstverständlech net dat ganzt Bild vum LVM2 Volumen ewechhuelen, awer de Dateiesystem an der RO a kopéiert d'QCOW2 Biller selwer, awer mir waren mat der Tatsaach konfrontéiert datt XFS aus dëser schlecht gouf, an net direkt, awer op eng onberechenbar Manéier. Mir hunn et wierklech net gär wann Hypervisor-Hosts op eemol um Weekend, an der Nuecht oder op Feierdeeg "stick" wéinst Feeler déi net kloer sinn wéini se geschéien. Dofir benotze mir fir XFS kee Snapshot Montagemodus RO fir Bänn ze extrahieren, kopéiere mir einfach de ganze LVM2 Volumen.

D'Geschwindegkeet vum Backup op de Backup-Server gëtt an eisem Fall festgeluegt duerch d'Performance vum Backup-Server, dat ass ongeféier 600-800 MB / s fir inkompressibel Donnéeën; e weidere Limiter ass den 10Gbit / s Kanal mat deem de Backup-Server ugeschloss ass an de Cluster.

An dësem Fall gi Backupkopien vun 8 Hypervisor-Server gläichzäiteg op ee Backup-Server eropgelueden. Also, d'Disk an d'Netz-Subsystemer vum Backup-Server, déi méi lues sinn, erlaben d'Disk-Subsystemer vun den Hypervisor-Host net ze iwwerlaascht, well se einfach net fäeg sinn, z.B. 8 GB / sec ze veraarbechten, wat den Hypervisor-Host ganz einfach ka veraarbechten. produzéieren.

Deen uewe genannte Kopieprozess ass ganz wichteg fir déi weider Geschicht, och d'Detailer - mat engem schnelle Intel P4500 Drive, benotzt NFS an, wahrscheinlech, benotzt ZFS.

Backupsatellit Geschicht

Op all Hypervisor Node hu mir eng kleng SWAP Partition vun 8 GB an der Gréisst, a mir "rollen" den Hypervisor Node selwer mat DD aus dem Referenzbild. Fir de Systemvolumen op Server benotze mir 2xSATA SSD RAID1 oder 2xSAS HDD RAID1 op engem LSI oder HP Hardware Controller. Am Allgemengen ass mir egal wat dobannen ass, well eise Systemvolumen am "bal readonly" Modus funktionnéiert, ausser SWAP. A well mir vill RAM um Server hunn an et ass 30-40% gratis, denken mir net un SWAP.

Backupsatellit Prozess. Dës Aufgab gesäit esou aus:

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

Opgepasst ionice -c3Tatsächlech ass dës Saach komplett nëtzlos fir NVMe Geräter, well den IO Scheduler fir si gesat ass:

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

Wéi och ëmmer, mir hunn eng Zuel vu legacy Node mat reguläre SSD RAIDs, fir si ass dëst relevant, sou datt se bewegen AS IS. Insgesamt ass dëst just en interessant Stéck Code deen d'Futtilitéit erkläert ionice am Fall vun esou enger Konfiguratioun.

Opgepasst op de Fändel iflag=direct fir DD. Mir benotzen direkten IO Contournement vum Puffer Cache fir onnéideg Ersatz vun IO Puffer beim Liesen ze vermeiden. Allerdéngs, oflag=direct mir maachen net well mir ZFS Leeschtung Problemer begéint hunn wann et benotzt.

Mir hunn dëse Schema erfollegräich fir e puer Joer ouni Problemer benotzt.

An dunn huet et ugefaang... Mir hunn entdeckt datt ee vun de Wirbelen net méi ënnerstëtzt gouf, an dee virdrun mat engem monstréisen IOWAIT vu 50% leeft. Wann Dir probéiert ze verstoen firwat d'Kopie net geschitt, hu mir de folgende Phänomen begéint:

Volume group "images" not found

Mir hunn ugefaang ze denken "d'Enn ass fir den Intel P4500 komm", awer, ier Dir de Server ausschalt fir den Drive ze ersetzen, war et nach ëmmer néideg fir e Backup ze maachen. Mir hunn LVM2 fixéiert andeems mir Metadaten aus engem LVM2 Backup restauréiert:

vgcfgrestore images

Mir hunn e Backup gestart an dëst Uelegmolerei gesinn:

Mir waren erëm ganz traureg - et war kloer datt mir net esou liewen kéinten, well all d'VPSe géife leiden, dat heescht datt mir och leiden. Wat geschitt ass ass komplett onkloer - iostat huet traureg IOPS an den héchste IOWAIT gewisen. Et waren keng Iddien anescht wéi "loosst eis NVMe ersetzen", awer en Abléck ass just an der Zäit geschitt.

Analyse vun der Situatioun Schrëtt fir Schrëtt

Historesch Magazin. E puer Deeg virdrun, op dësem Server war et néideg e grousse VPS mat 128 GB RAM ze schafen. Et schéngt genuch Erënnerung ze sinn, awer fir op der sécherer Säit ze sinn, hu mir eng aner 32 GB fir d'Swappartition zougewisen. De VPS gouf erstallt, huet seng Aufgab erfollegräich ofgeschloss an den Zwëschefall gouf vergiess, awer d'SWAP-Partition blouf.

Configuratioun Fonctiounen. Fir all Cloud Server de Parameter vm.swappiness war op Standard gesat 60. An SWAP gouf op SAS HDD RAID1 erstallt.

Wat ass geschitt (no der Redaktioun). Beim Backup DD produzéiert vill Schreifdaten, déi an RAM-Puffer plazéiert goufen ier Dir op NFS schreift. System Kär, vun Politik guidéiert swappiness, huet vill Säite vu VPS-Erënnerung an d'Swap-Beräich geplënnert, déi op engem luesen HDD RAID1 Volumen läit. Dëst huet dozou gefouert datt IOWAIT ganz staark gewuess ass, awer net wéinst IO NVMe, mee wéinst IO HDD RAID1.

Wéi de Problem geléist gouf. D'32GB Swap Partition war deaktivéiert. Dëst huet 16 Stonnen gedauert; Dir kënnt separat liesen iwwer wéi a firwat SWAP sou lues ausschalt. Astellunge goufen geännert swappiness zu engem Wäert gläich wéi 5 iwwerall an der Wollek.

Wéi konnt dat net geschéien?. Éischtens, wann SWAP op engem SSD RAID oder NVMe Apparat wier, an zweetens, wann et keen NVMe Apparat war, awer e méi luesen Apparat deen net sou e Volumen vun Daten géif produzéieren - ironesch ass de Problem geschitt well deen NVMe ze séier ass.

Duerno huet alles ugefaang wéi virdrun ze schaffen - mat Null IOWAIT.

Source: will.com