Multus gratis RAM, NVMe Intel P4500 omniaque lentissima sunt - narratio additamenti infelicis partitio VERTI

In hoc articulo, dicam de condicione quae nuper incidit cum uno ministrorum nostrorum in nube VPS, quae me per aliquot horas reliquit impeditum. Fui servientes Linux configurans et sollicitudinem circiter XV annos, sed hic casus omnino non convenit in praxim meam - pluribus falsis suppositis feci et paulo desperatis rebus antequam causam quaestionis recte definire ac solvere possem. .

exordium

Nos nubem mediocrem agunt, quam in servientibus vexillum construimus cum hac configuratione - 32 coros, 256 GB RAM et 4500TB PCI-E Intel P4 NVMe pellunt. Hoc configuratione vere placet quia removet necessitatem curandi de IO supra caput, dum rectam restrictionem in gradu VM exempli generis praebens. Quia NVMe Intel P4500 infigo peractio habet, simul providere possumus tam plenum IOPS commeatum machinis ac tergum repono ad tergum servo cum nulla IOWAIT.

Sumus unus ex illis credentibus antiquis qui hyperconverged SDN et aliis non utuntur hilares, luxu- biles, iuvenum rerum volumina VM condere, credentes simpliciorem rationem esse, facilius eam in condicionibus "guru principalis abiit. ad montes. " Quam ob rem condimus volumina VM in forma QCOW2 in XFS vel EXT4, quae supra LVM2 explicantur.

Etiam QCOW2 uti cogimur producto utimur ad orchestrationem - Apache CloudStack.

Ad tergum praestandum, plenam imaginem voluminis accipimus ut scapulae LVM2 (sic, Scimus LVM2 snapshots pigri esse, sed Intel P4500 adiuvat nos hic quoque). Facimus lvmcreate -s .. et cum auxilio dd exemplum tergum mittimus ut servo remoto cum ZFS repono. Hic adhuc paulo progressivus - post omnes, ZFS notitias in forma compressa reponere possumus, eamque celeriter utendo restituere possumus. DD aut singula VM volumina utens mount -o loop ....

Non plenam imaginem voluminis LVM2 removere, sed tabellam conscendere in the RO ipsas imagines QCOW2 exscribas, quod ante XFS malae facti sumus, et non statim, sed inaestimabili modo. Hoc vere non placet cum hypervisoris exercituum "lignum" subito in weekends, in nocte vel in festis propter errores qui non clarent quando evenient. Itaque pro XFS non utimur snapshot ascendentem RO Volumina excerpenda, totum LVM2 volumen simpliciter imitamur.

Celeritas tergum ad tergum servientis in casu nostro determinatur ab exsecutione servientis tergum, quae est circiter 600-800 MB/s pro notitia incompressibili, ulterior limitatio est canalis 10Gbit/s cum quo servo tergum iungitur ad botrum.

In hoc casu, exemplaria tergum 8 servoriorum hypervisoris simul sunt onerati uni servo tergum. Ita, disci et subsystematum retis servientis, cum tardiores sint, disci subsystema virtutum hypervisoris onerare non permittunt, cum simpliciter processus non valentes dicere, 8 GB/sec, quae hypervisoris exercituum facile possunt. annona.

Processus supra describendus magni momenti est ad ulteriorem fabulam, inclusa singularia - celere Intel P4500 utens, NFS utens et, fortasse, ZFS utens.

Tergum fabula

In unaquaque nodi hypervisoris parte parvam SWAP partitionem 8 GB magnitudine habemus, et nos "nodum hypervisoris" ipsum utendo DD ex imagine. Ad volumen systematis servientibus utimur 2xSATA SSD RAID1 vel 2xSAS HDD RAID1 in LSI vel HP ferrariae moderatoris. In genere, quid intus est, non curamus, cum ratio voluminis nostri in modo "paene legere" operetur, excepto RES. Et quia multum RAM in servo habemus et 30-40% liberum est, de SWAP non cogitamus.

Tergum processus. Hoc negotium spectat ut hoc aliquid:

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

Ut attendere ionice -c3re vera haec res prorsus inutilis est NVMe machinis, quoniam IO schedula illis ponitur;

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

Tamen plures nodos legatorum habemus cum RAIDS conventionales SSD, ad eas hoc pertinet, ut moveantur. AS*. Super, hoc est an interesting fragmentum codicis quod vanitatem explicat ionice in casu tali conformationis.

Attende ad vexillum iflag=direct ad DD. Recto IO utimur, praetermittentes quiddam cache ad vitandum necessarias substitutiones IO buffers legentes. Sed oflag=direct non quod invenimus ZFS quaestiones perficiendi cum ea utentes.

Hoc schemate pluribus annis sine problematibus feliciter usi sumus.

Et tunc incepit... Inspeximus unam e nodi iam non subnixam fuisse, et prior cum monstrosa IOWAIT of 50 currit. Cum intellegere conamur cur exscribendum non sit, sequenti phaenomeno invenimus;

Volume group "images" not found

Cogitare coepimus "venit finis pro Intel P4500", tamen, antequam servo averteret ut coegi reponeret, tergum praestare adhuc erat. Statuimus LVM2 restituendo metadata ab an LVM2 tergum:

vgcfgrestore images

Tergum iniecimus et hoc oleum pictura vidimus;

Iterum tristes eramus - manifestum est quod sic non potuimus vivere, cum omnes VPSs paterentur, quod etiam passuri sumus. Quid factum sit, omnino incertum est. iostat miserabilis IOPS et supremus IOWAIT. Nullae notiones praeter "NVMe reponamus", sed perspectio in tempore accidit.

Analysis rei gradatim

Historical magazine. Paucis ante diebus, in hac servo necesse erat magnam VPS cum 128 GB RAM creare. Satis memoriae visae sunt, sed ut in tuto essemus, aliam 32 GB ad PERMUTATIO collocavimus. VPS creatus est, negotium suum feliciter consummavit et incidentia in oblivionem venit, sed partitio RES RES mansit.

Configurationis Features. Nam omnes nubes servers parametri vm.swappiness profectus est ad defaltam 60. Et SWAP creatus est in SAS HDD RAID1.

Quod factum est (secundum editores). Cum tergum sursum DD multam notitias scribentium productas, quae in RAM buffers ante scribebant NFS posita erat. Core systematis, ductus consilio swappinessferebatur, multae paginae VPS memoriae ad PERMUTATIO area, quae in lento HDD RAID1 volumine sita erat. Inde ad IOWAIT valde valde crescens, sed non propter IO NVME, sed propter IO HDD RAID1.

Quam quaestionem solvitur. 32GB VERTO partitione debilitata est. Hoc factum est XVI horis: legere potes separatim quomodo et quare RES tam lente vertit. Optiones sunt mutata swappiness ad valorem = * 5 omnia super nubem.

Quomodo hoc non fit?. Primo, si RES in SSD RAID vel NVMe notae essent, deinde si nulla esset NVMe fabrica, sed tardius artificium, quod tale volumen notitiarum non produceret - ironice factum est quaestio propter hoc NVMe nimis celeriter.

Post hoc, omnia sicut prius incohata sunt - cum nulla IOWAIT.

Source: www.habr.com