Sziasztok!
Nálam jóval tapasztaltabb ZFS szakértők vannak a fórumtársak között, meg sokan láttunk sokfélét, így szeretnék tippeket/ötleteket gyűjteni a témában.
A példa kedvéért adott egy KKV virtualizáció, mondjuk 10db 2TB-os HDD-vel (tételezzük fel h. enterprise NL-SAS, a diszkek alapvető problémáit most hagyjuk ki). A diszkek egy olyan szerverben vannak amiben van jó RAID kontroller, de ha ZFS irányba mennénk akkor ez természetesen cserélődne egy HBA-ra.
Tehát, az alapprobléma: minden szép és jó, virtualizáció megy a vason, de van néhány VM aminek ugyan kisebb a mérete, de nagyobb az IO igénye, jellemzően peak szerűen, ha pedig nem peak szerűen, akkor prod időben, de kis adatmennyiségen. Az egyszerűség kedvéért hívjuk ezeket a vmeket DB szervernek (pl. postgres, mariadb, akármi, de kezelhető, 10-20-30G méretig bezárólag). Ezen felül van mondjuk szintén pár VM ami viszont bazi nagy, vagy épp nem is io igényes (appszerver, fájlszerver, stb.), hívjuk ezeket FS szervernek.
Nagyon alap megoldás h. a HDD-k mellé veszek mondjuk 2 2TB-os SSD-t, berakom egy raid1-be, átrakom rá az IO igényes(ebb) VMeket és örülök.
De mi van akkor, ha én olyat szeretnék, ami ennél egy picit szofisztikáltabb/egységesebb és az összes diszkemet egy logikai egységben kezeli. Tehát ezen a ponton lenne mondjuk 2db 2TB-os Enterprise SSD, meg 10db 2TB-os NL-SAS HDD.
És akkor itt jön a dilemma, melyik az az irány amivel fel lehet turbózni a HDD-k sebességét úgy, hogy ezt az fs/kötetkezelő megoldja a VM-ek alatt?
Jelenleg két opciót látok:
- dm-cache (LVM)
- L2ARC, ZIL, SLOG (zfs)
Igenám, de nincs a topicban ilyen mély tapasztalatom, Enterprise storage tud ilyet, azt használtam és jól működik (egy poolon belül több tier, meg cache raid stb.). Így az lenne a kérdésem, hogy ezen a szoftveres vonalon ki mit látott már működni jól, van-e olyan amivel érdemes próbálkozni, vagy egyszerűen engedjem el és válasszam szét az adattárolókat és a rajta futó cuccokat, ne akarjak egységes adattárolást alá?
Köszi!
Hozzászólások
én inkább a dedikált ssd irányába mennék.
Még akár az is jó, ha egy VM-en belül az adatbázisnak adsz csak ssd diszket.
Felesleges csicsázni, ha semmi érv az egységesítés mellett a "cool" faktoron kívül.
Minnél több rendszerre teríted szét az SSD-t, annál valószínűbb, hogy nem fogja tudni rendesen kiegyenlíteni a peak-eket ott, ahol kéne.
Ráadásul a COW file rendszerek, mint a zfs nem optimális választás tranzakciós adatbázisok alá. ZFS alá egyébként meg felesleges a HBA, hacsak nem valami rendes külső FC/iscsi storage van, de akkor meg a storage kezeli a cache/dedup/stb feladatokat.
+1, a legegyszerűbb jó megoldás a legjobb általában.
Igen, az alapötletem nekem is az volt h. kap a szerver egy SSD tömböt, abból meg a DB VM-ek egy új driveot és oda költözik az adat. Csak aztán elkapott a gépszíj, hogy nem lehetne-e valami olyan varázslatot csinálni, ahol az FS VM-ek is kapnak valami boostot, ha már van SSD. Nagyon tipikus, mondhatni tucat felhasználásról beszélünk, pár VM üldögél egy 2 raid6-os pool-on (h. legyen pici write performancia is) és ezekben a VM-ekben történik a csoda, miszerint mancika felmásol egy max pár mbos fájlt, szerkeszti, stb, miközben néhány belső app az adatbázis kb. "hot" részében dolgozgat kis insertekkel, nem nagy számosságban.
Nekem itt jutott eszembe h. egy write cache-el ezt azért szépen lehetne csinálni, csak aztán picit elvesztem a sok doksi olvasásában, ahogy már írtam is a dm-cache és társai környékén.
Jelenleg ott van (lesz majd) a szűk keresztmetszet h. a write IO a raid6 miatt limitált erősen, olvasni még egész jól tud a rendszer, ott azért a karszám megoldja a dolgot most is.
A ZFS úgy merült fel h. pl. a Proxmox is "erőlteti" h. használj a VM-ek alá zpool-t, ami egyébként egészen jó is a gyakorlatban, csak ezekkel a kiegészítő csiribákkal nem vagyok gyakorlati szinten tisztában, így született a topic.
Azért ha valakinek nincs egy ilyen faszán működő setupja, akkor valszeg én is maradok a klasszikus elkülönített SSD datastore-nál, ahogy írtad is.
A ProxMox nem erőltet semmit, ZFS-sel települ alapértelmezetten, de amúgy elosztott, több VM-es használatra, ahol esetleg szempont a HA is, inkább Ceph-et javasolnak. De dönthetsz úgy, hogy LVM-et használsz például, vagy BTRFS-t.
Ha DB és minden más rendszer a téma, én lehet, hogy a DB-ket amúgy külön tenném egy Ceph clusterre, hogy legyen HA (máskülönben a másik node-on való elindításhoz át kell migrálni a disket ZFS szinten, ami nagyobb diskek esetén több idő).
Blog | @hron84
via @snq-
biztos?
Egyrészt a mysql önmagában nem fedi le a tranzakciós adatbázisok halmazát, másrészt elég sok féle io profil van, a teszt nem fedheti le mindent.
Harmadrészt a teszt nem olyan setup-al futott, mint amit most vizsgálunk, vagyis egy rakás vm-et ráraktak egy közös zfs poolra.....
Negyedrészt a teszt Azure vps-en futott, innentől kezdve a ROTFL kategória, ugyanis ki tudja milyen storage backend volt valójában mögötte, milyen IO throttling-al, stb.
Egyébként SSD esetén még lehet teljesen oké , de HDD esetén egy COW semmiképp nem való full random io r/w workload alá.
persze, én ezekkel teljesen egyetértek, amiket írsz... de azért vannak még szempontok...
1. a mysql önmagában nem fedi le a tranzakciós adatbázisok halmazát, tessék van egy postgresql-es benchmark ... bár SSD-ken van a teszt, a zfs annyira azért nem marad le az ext4től
Egy HDDnél nem a filerendszer maga lesz a bottleneck, hanem a diszkek.
2. a "néhány" vm az szerintem nem "rakás vm"...
3. ha nem snapshotolod szét a zpool-t, nem fog a pool megdefragmentálódni és szinte pont úgy fog teljesíteni random io-nál, mint az ext4. nem kell snapshotolni s kész.
4. zfsnél érezhetően sokat tud dobni a teljesítményen pl. a compression. ezt sem én mondom
5. zfsnél ha kell egy kis kakaó, még mindig tudsz egy SSDt berakni zil/slog cache-nek, bár én is a dedikált ssd fele mennék inkább
6. ext4-re én, személy szerint már csak azért sem bíznék egy "tranzakciós adatbázist", mert power loss esetén nagyon sokszor a "loss" szokott győzni... vagy kernel crashnél
7. zfs-nél dolgokat tudsz megtenni egy adatbázissal, mint pl. temporálisan beállítod a datasetedre sync=disabled, hogy egy slave hamar utolérje a mastert. Vagy tudsz instant slave-et csinálni (adatok + binlog pozíció) egy snapshot segítségével, anélkül, hogy megállítsd a mastert (persze, mysqlnél meg lehet ezt csinálni innobackupexszel is, csak kell neki egy rakás disk space, load és idő)
Ha sok az update az adatbázison, akkor a zfs fragmentálódik rendesen, mert új blokkba ír minden változást. A snapshot érdemben nem sokat változtat, az csak annyi plusz, hogy a régi blokkokat nem használja újra amíg él az adott snapshot.
HDDnál nyilván a "vas" a bottleneck, de minnél inkább fragmentált az adat, és minnél inkább random IO van kis blokkmérettel, annál roszabb a teljesítménye.(pontosabban annál inkább közelíti az elméleti minimum teljesítményét.)
SSD esetén nyilván nem számít a fragmentáció, mert nem szekvenciális az elérése mint a HDD-nek, úgyogy a random IO-t is ugyanolyan gyorsan szolgálja ki,
éppen ezért a ZFS is teljesen jól teljesít ha tisztán SSD van alatta. Egy hibrid felállásban, mint amit a topic indító írt már nem vagyok erről meggyőződve.
A compression-al egyetértek, az mindíg is az egyik érv volt mellette - a diszk hely kihasználás mellett -hogy a cpu teljesítmény rovására lehet az io teljesítményt javítani.
powerloss nem értelmezhető, mert szünetmentes + bbwc controller nélkül csak olyan szervert üzemeltetünk, ahol nem gond ha előfordulhat kisebb adatvesztés, és elég, ha van megbízható mentés. (A kernel crash esetén azért egy IO sync még belefér, az adatbázis így is inkonzisztens lesz, de rollbackelhető a logokból.)
Tekintve, hogy ZFS esetén a proxmox is asszem talán ZFS snapshotokkal operál, a "ne használj snapshotokat" egy viszonylag kemény megkötés is tud lenni, ha nem labort építesz.
Blog | @hron84
via @snq-
mi a cel? mi az elvart teljesitmeny? (throughput/iops/latency)
zfs-t nem a teljesitmenye, hanem a szolgaltatasai miatt hasznalunk elsosorban. ha nem lehet elengedni a porgo rozsdat, legtobbet az arc/zil-lel es a multi-vdev pool kialakitassal tudsz segiteni.
Alapvetően a cél az lenne, hogy a jelenlegi 2 NL-SAS írási sebességét megemeljük úgy h. jól érezze magát a diszk poolon egy SQL szerver is. Az adatmozgás minimális, MB-okban mérhető, az elvárt IOPS nyilván nem 10000 :)
Pontos számokat nem tudok mondani, de mondjuk egy becslés legyen itt.
Jelenleg: van 300 IOPS write teljesítményem, jó lenne ha ez mondjuk 5GB erejéig tudna 2000-et. Ha elfogy a write cache, akkor persze visszamegyünk a 300-ra, ez van. De a burstöknél jól jönne a többlet.
A read az nyilvánvalóan marad ami, maximum cachelheti a "hot" régiót és tök jó lenne a mostani 4 diszk preformanca helyett ha néhány dolog ami cache-ben van az kijönne 4-5k IOPS-el.
Értsd: nincs most sem baj, nem rossz a teljesítmény, csak szeretném ezt valahogy megtunningolni és érdekel h. mik a lehetőségek, amik nem túl egzotikusak és hozhatnak javulást globálisan, nem dedikáltan felhasználom az SSDket és kész.
pont azt kerdeztem, hogy mi a "jól érezze magát"...
Ha elfogy a write cache, akkor persze visszamegyünk a 300-ra, ez van. > ez nem igy mukodik. olvass utana mit/hogy csinal a zil.
érdekel h. mik a lehetőségek > ezt leirtam fentebb. multi-vdev pool lesz a baratod, pazarlasnak tunhet a vdev-enkenti redundancia, de ez a valamit valamiert esete... :)
A read az nyilvánvalóan marad ami > arc, l2arc.
azert okolszabaly, ha SSD sebeseget szeretnel, SSD poolt kell epits, onnantol mar csak a vdev-elrendezesen kell gondolkozz
Értem én h. pontos számokat szeretnél, de lássuk be ez jelen állapotban nem értelmezhető.
Van egy 300 write IO képes "tömb", amin kb. köszi szépen jól elvan minden. A DB jellegű dolgokat tenném át SSD-re, hogy még jobban érezzék magukat, innen indult a topic. De ha már lesz SSD kíváncsi voltam arra, hogy nem lehetne-e megoldani, hogy minden jobban érezze magát, tekintve h. nem napi 2TB adat változik a cachelés blockdevre egészen használható ötletnek tűnt számomra. Hogy ez a számok tükrében hogyan néz ki, az jelen ponton még nem igazán érdekel. Ha mondjuk 5-10GB írásáig tudja az SSD performanciájának a felét az elképzelt io rendszer összeállítás (dm-cache, zfs l2arc+zil+kutyafüle) egy fél órás időablakban, az tök jó lenne és nagyságrendekkel jobban érezné magát _minden_. De hangsúlyozom, a 300IOPS is elegendő jelenleg, csak fantáziálok h. mit lehetne csinálni és az miért lenne jó vagy rossz.
nem mondtam olyat, h pontos szamok. nagysagrendileg is elg, hogy pl local nvme 1-2millio iops, <1ms response az elvart, vagy egy koszos HDD raid tomb 1-200 iops-a, 3-500ms-kel...
a gep nem erez lofaszt sem, azt max te teszed. o a szamokbol ert. :)
h. mit lehetne csinálni és az miért lenne jó vagy rossz. > barmit... viszont igy nehez lesz segiteni a tervezesben :) rosszul teszed fel a kerdest. a valasz 42!
elso korben azt kell eldontsd, hogyan specifikalod az elvart performancia-ertekeket.
A gond az h. itt nincs elvárás, nekem van csak elvárásom. Ahogy korábban írtam: ez jelenleg működik és elégedett az aki használja. A DB néha lehetne gyorsabb. Ez ugye akkor van ha mancika épp nem 5 megás fájlt tölt fel, hanem mondjuk 2gigát mert kapott pár CAD fájlt.
Az egyszerű megoldás h. az a 2DB szerver átmegy SSD-re és pont.
Engem meg a bonyolultabb érdekelne, ahol nem megy semmi sehova, hanem 2 enterprise ssd-t felhasználok arra h. ezeket a ritka bottleneckeket cacheléssel kiegyenlítsem. Mindenféle szintetikus tesztet találtam a neten, nem akarok feleslegesen belebonyolódni a millisecekbe, mert nincs értelme. Tételezzük fel h. az SSD 1.92-es, tud mondjuk 60k IOPS-t. A backing store (HDD) meg tud mondjuk 300 IOPS-t a cél az lenne h. a 60k IOPS-t hajtsuk meg amikor kell (értsd beesik 5G adat), onnan meg pakoljuk le a 300IOPS-es tömbre a háttérben. Hogy ezt mi tudja jól megcsinálni, na ezért tettem fel kérdést. Mindenki másra esküszik, a millisec azon is múlik ki gyártotta az SSD-t, ennyire nem kell ebben az esetben pontosan tervezni, mint pl. amikor egy 80TB-s erasure code-os ceph backup poolt csinálsz.
De ennél többet nem is akarok róla konkretizálni, csak az elmélet, a tapasztalatok, meg az érdekelt h. itt inkább az jön ki h. ez hülyeség és dedikált ssd a jó választás, vagy esetleg valaki azt mondja h. nem hülyeség, használ ilyet, működik és meg van vele elégedve, x,y,z technológiának menjek utána és boldog leszek. Ha még azt is leírja h. az a tapasztalat h. az SSD teljesítményének max a negyedére számítsak, de azt tudja az SSD méretének feléig mondjuk, az is segítség.
nekem van csak elvárásom > akkor mondd el. nem olyan nehez, 2-3 erteket kell csak deklaralnod kb. :)
onnan meg pakoljuk le a 300IOPS-es tömbre a háttérben. > az SSD nem magia, olvasd el hogy mukodik a zil es mi menten kell meretezned.
Mindenki másra esküszik > nem istenrol meg a kiralynorol van szo, csak egyszeru szamokrol...
De ennél többet nem is akarok róla konkretizálni, csak az elmélet, a tapasztalatok, meg az érdekelt h. itt inkább az jön ki h. ez hülyeség és dedikált ssd a jó választás, vagy esetleg valaki azt mondja h. nem hülyeség, használ ilyet, működik és meg van vele elégedve, x,y,z technológiának menjek utána és boldog leszek. Ha még azt is leírja h. az a tapasztalat h. az SSD teljesítményének max a negyedére számítsak, de azt tudja az SSD méretének feléig mondjuk, az is segítség. > 42! hint: amiket irsz, azok mind igazak es nem igazak. egyszerre! specifikacio nelkul schrodinger macskaja, hogy amit en most hasrautesre bemondok neked, es nalam bevalt pool elrendezes (tudnek parat benyogni a mirror hdd-tol a full flash-ig, mind aktivan hasznalt, mas-mas feladatra...) az _neked_ jo lesz-e... ne a kalapacsod alapjan nezz mindent szegnek, hanem az adott feladatra keress megfelelo tool-t!
de azt tudja az SSD méretének feléig > jo, lehet negyedjere mondom el, de olvass utana hogy mukodik a zil :) please!
" a cél az lenne h. a 60k IOPS-t hajtsuk meg amikor kell (értsd beesik 5G adat), onnan meg pakoljuk le a 300IOPS-es tömbre a háttérben."
Használj Windows Storage Spaces-t :)
https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityb…
vagy hasznalj bbu-backed RAM-cached hwraid controllert! :)
azok többsége is tud valamiféle mixed poolt, ahol ssd-t használ cache-nek.
"van az a penz", pl. cachecade licensz.
erre mondjuk én is kíváncsi lennék, h látott-e már itt valaki ilyet működni...
mondjuk egy olyan esetben, ahol 2G cache van (75-90%-ban írásra) és oda van adva neki párszáz GB enterprise grade SSD "cache"-nek.
kérdés az is, hogy ez pl egy dm-cache-el mennyire összehasonlítható
Nem teljesen összehasonlítható de nekem Synologyn van olyan h 2x512gb ssd cache a 4x4tb raid5 btrfs alatt.
Csodát tett főleg a dockerrel és a mentéssel.
Gábriel Ákos
Pont vmi ilyesmire gondoltam. Az bcache v dm-cache a gyakorlatban amit a syno csinal?
ha ugyanabba a pool-ba teszel SSDt és HDDt, akkor sokat nem nyersz vele, a pool a leglassúbb diszked sebességét fogja tükrözni...
berakhatod az SSD-t L2ARC cache-nek, ez fog az olvasási sebességeden segíteni, berakhatod ZIL/SLOG cache-nek, ez pedig írási sebességeden...
de berakhatod az SSD egy részét ennek, a másik részét annak, nyilván mirrorban mindkét esetben...
ha viszont pont egy nagy file-ot fogsz másolni valamelyik "fileszerverre", akkor az megtöltheti a write cache-et, tehát az adatbázisok ezt meg fogják érezni, ugye...
ha nem olyan nagyok azok a db szerverek, nem lenne jobb azoknak külön poolt csinálni, csak SSD-re?
Mérni kell , pl fioval.
Legygyorsabb nyilván a különálló ssd-k lesznek. Én ezt használnám. Ha nagyon magas az iops igény akkor gondolom nem újdonság, hogy DC ssd kell. Amire ügyelj az, hogy PLP-s legyen, máshogy működnek, (hasonlóak mint az akkus , nem felejtő RAM-os hardver RAID kártyák, mindkettő a gyors RAM ba ir és nem a lemezre rögtön). A gond a kis blokkos random szinkron irásokkal van, az adtbázisok, vm ek meg pont ilyenek leginkább . Proxmoxnál pl a no-cache a vm-ek alpértelmezett beállítása (Úgy emlékszem ez azért nem sima szinkron írás, a lemez cache bekapcsolva marad) HDD és aszinkron irással nincs gond van elég RAM, ssd -vel meg főleg nincs. Viszont a szinkron 4K- nál az ssd-k szétterülnek tudásban 2M/sec -től 200 MB/sec-ig. (Más módokban már nincs ekkora különbség, csak itt)
Szóval csak PLP-s. Ne tévesszen meg az "Nvme Pro" és hasonló felirat , az csak egy platform és marketing , nem sebesség. 60-80 MB/sec már szerintem ebben a műfajban jó. HDD itt tud 100 iops/sec -et. ZFS ezen a ZIL loggal próbál segíteni, elöször ide naplóz szinkron módon, ha ez kész utána már mehetnek az adatok aszinkron módon a a HDD-kre vagy lassabb ssd-kre. Nem irási cache , ezt csak irja zfs, naplóz vele, ha van valami leakadás, újrainditáskor innen szedi a hiányzó adatokat. De aZIL csak a szinkron írásoknál használt, semmi más esetben nincs hatása, de HDD-k esetén adatbázisoknak jót tesz, de ne várd azt mint a "nativ" ssd-k esetében. De inkább mérjél, minden ilyen mérés "szintetikus, nincs egyoldalú olyan terhelés amiket ezekkel teszttekkel mérsz, de összehasonlitásokhoz jók.
Egy fio a szinkron iráshoz:
fio --name=ssdtest --filename=testfile1 --size=100M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1
vagy :
https://blog.claryel.hu
Egy teszt erejéig ha lehetséges egy asztali nvme ssd-vel, ami tud ugy 8 MB/sec-et 4 k random szinkron irásban, berakni zil-nek, a zfs tud választott méretű blokkokat , érdemes erre a részre itt 16K -ra tenni, egy próbát megér. Hosszú távon az asztalinak nincs nagy jövője ZIL-ként., de tesztre jó. A 2000 szerintem elérhető. ZIL pár másodpercenként ir/töröl, ez legalább nem fogy el.
https://blog.claryel.hu
ZIL pár másodpercenként ir > pont forditva ertetted, ugye? :)
Ja, szóval próbálok értelmesen írni, néha sikerül .... :-)
Igen ZFS ZIL -t csak irja, de kizárolag ha szinkron irás történik. Naplóz, Olvasni meg akkor ha összezuhanás votl, és újrainditáskor ez alapján a napló alapján fejezi be az irást. Nem cache.
https://blog.claryel.hu
Persze, de mégis mit mérjek, ez egy prod rendszer, ahol kiegészíteném a rendszert vagy ilyen csoda cache-el v. natív ssd datastore-al, maga a felvetés is ebből jön h. mi éri meg jobban. Az alap kérdés az h. merre érdemes menni egy klasszik KKV single szerver virtualizációval ahol kellene nagy adatot tárolni, de nem lenne baj ha a napi változó dolgok azért gyorsabban működnének mint a sima HDD tömb esetében. Tisztában vagyok vele h. nincs de facto megoldás, csak kíváncsiskodni akartam h. ki mit javasol (pl. dm-cache-t még senki nem javasolta, pedig jókat olvastam róla)
A diszkekbe ezért nem akartam belemenni, mert Ceph-et is üzemeltetek pl. és ott ugye kapcsiból téma volt már évekkel ezelőtt is a PLP, meg sync,async írás milyen SSD-n milyen teljesítménnyel tud menni és miért. Mostanában a HDD piacon meg ugye az SMR és társai. Szóval igen, az alap h. enterprise SSD meg enterprise NL-SAS (pl. Samsung PM***, meg WD HC***) A desktop vackok pro elnevezéssel nem visznek be a málnásba, Samsung 850 PRO környékén magam is mértem h. mi a helyzet és elég egyértelmű.
A dm-cache oldalról közelítve, az azért jó, mert mögé tudom tenni a jelenlegi tömböt, nem kell ZFS irányba menni, plusz mellérakok cache-nek egy SSD tömböt és még le se kell állítsam. Állítólag :)
A ZFS meg azért jó, mert van egy csomó featureje amit később akár még hasznosítani is tudnánk, így többet tudna rendszer a jelenlegi "korlátozott" LVM-hez képest.
Ok, maradjunk aZIL-nél . Szóval Mysql, Pgsql alapértelmezetten nem használ szinkron irást, csak ha te átállítod. Proxmox vm no-cache default beállitása szintén nem használ szinkron írást. Ha nálad is ez a helyzet és ha beraksz egy ZIL ssd-t ezekhez a default beállításokhoz, akkor feleslegesen dolgoztál a ZIL-re egy gramm irás nem kerül.
https://blog.claryel.hu
Vagyis marad az ssd-re költözés a default sql, vm beállításokkal. Nem tartozik már a témához, de azért találták ki a ZIL-t , hogy ZFS is olyasmi legyen mint egy drága akkus, nem felejtő RAM-os hw raid kártya.
https://blog.claryel.hu
Én próbálkoztam ilyennel proxmox alatt, a vége az lett hogy az ssd-ből kapott pici slog-ot meg zil-t a hdd-s pool és lett külön ssd pool.
Lehet köztük mozgatni a volume-okat ha éppen kell.
Az 1M IOPS-t tudó enterprise ssd egész más kávéház mint akármilyen enterprise 15k SAS diszk.
Gábriel Ákos
És az SLOG meg ZIL hogyan teljesített a ZFS-el?
Nyilván az enterprise SSD, ami annyi IOPS-t tud, az tök más, meg azt nem is pazarolnám ilyesmire, de itt azon ment a matek ha beleraknánk a gépbe 2db 960-as pm883-at, akkor az kisimítaná-e a napi 3x előforduló write IO torlódást. Kb. ennyit kellene megoldani vele, nem konstans 8000IOPS-t akarunk belőle kihozni, mert az nyilván nem is reális.
Az én usecase-emen egyszerűbb volt az egészet direkt ssd-re tenni, az is lett.
Nézz utána melyik ssd-t nem szabad zfs alá tenni. pm9a3 -at ajánlották, azt vettem, hasít mint állat.
Gábriel Ákos
Egyébként pont proxmox témakörben ezt a kettőt nézegettem, mindkettő dm-cache:
https://blog.jenningsga.com/lvm-caching-with-ssds/
https://blog.delouw.ch/2020/01/29/using-lvm-cache-for-storage-tiering/
Sebesség vs adatbiztonság: nem ismerem a dm-cache-t , de a blogban ott ez az utolsó sor az ssd -cache létrehozáskor:
Vagyis ez a cache ssd writeback lesz, proxmox vm-et "átveri", ha az alapértelmezett no-cache a vm beállítás, vm azt hiszi hogy már lemezen az adat, de a cache-ben van, nem a lemezen.
Pover loss esetén ezek mennek a levesbe. Hogy ez mennyire gond nincs tapasztalatom , lehet hogy simán túléli. Proxmox ezt unsafe-nek tartja.
Mintha unsafe writeback re állitanád a vm -lemezét a proxmoxban. Bekapcsolja a cache-eket és 3-4-5 szörös iops emelkedés lesz, de csökken az adatbiztonság.
https://blog.claryel.hu
Igen, de azt ne feledd h. ez a writeback egy picit mást jelent. Ez a writeback cachevol-odra szól, a doksi szerint is:
Tehát a writeback azt jelenti h. levési a cachepoolba és azt mondja a processnek h. oké, le van írva. Ezzel szemben a writetrough az leírja a lassú backing store-ra is és akkor oké az IO művelet. Kb. a writeback a write cacheelés a cachpool device-on, a writetrough meg csak read cache.
A cache itt az SSD-t jelenti. Plusz én ezt csak olyan szerverben játszanám meg amiben BBU raid van, így azért jelentősen kisebb a kockázat.
Ha jól értelek, ugyanarról beszélünk. Van egy ssd dm-cache lemezed és az első blog link szerint ez writeback, (a másodikon nem, de ott nincsenek sebességadatok, de nem is ez a célod, maradojunk az elsőnél,) .
Irás bekerül gyors ssd-re , megjelöli "piszkosnak" - marked dirty - és majd valamikor a végleges főtárolóba kerül , vagyis a HDD-kre) . Vm felé ez úgy látszik, hogy irás rendben, megtörtént. Na most jön egy power loss, a "dirty marked" adatok elvesznek. Ezen nem segit a BBU-s raid, ezek az adatok, blokkok még nincsenek a bbus raid nem felejtős RAm-jában, ha jól gondolom.
Visszatérve a zfs-re, (meg nem zfs-nél is) a legnagyobb sebességet úgy tudod elérni sajnos ha az egész ssd lemezt pcie passthrough-val oddadod egy vm-nek, igy vm nativan eléri a lemezt, egyébként meg mindenféle iráserősités meg különböző rétegek ékelődnek be, kikapcsolt cach-ekkel.
https://blog.claryel.hu
Egyről beszélünk, csak a következtetés nem helyes sztem :)
Tehát writeback esetén a dm-cache azt csinálja h. SSD-re megy az írás a data kötetbe, dirty bitmap a meta kötetbe és amikor majd a slowmo hdd kötet ráér, akkor átkerül rá az adat amit writecacheltünk az SSD-re. Powloss esetén nincs semmi, hiszen az SSD-n van a motyó, folytatjuk a dirty bitmap alapján a HDD-re "átvezetést". Pont az a különbség h. itt a writeback úgy értendő h. az SSD a writeback cache, ahhoz meg nem kell igazából BBU se meg semmise, hiszen kinn van rajta az adat már. Még szebb esetben meg az SSD cache-t is egy BBU protected RAID1-re rakod és akkor végképp semmi ilyen para nem lehet.
Nem ismerem az lvmcache-t (dm-cache-t), újrainditásnál a "dirty blokkokat" helyre teszi azt nem tudtam.
Macera az egész aszinkron irás, hol milyen cache van, host page cahche, vm cachelése. Szinkron irásnál mincs ilyen, cserébe jó lassú , vagy vehetsz jó drága lemezeket, amik még mindig lassúak lesznek :-) .
https://blog.claryel.hu
Ki fogom még idén próbálni egy teszt szerveren ezt a dm-cache mókát, mert pont a szinkron, aszinkron stb. problémakör miatt elengedtem a ZFS L2ARC,ZIL,SLOG variálást, ráadásul ha van BBU raid-em a gépben, akkor az SSD tömbből csinálok cache-t, így az is biztonságban van powerloss esetére is. Meglátjuk mit lehet ezzel kihozni az egészből, lesz egy kis szabadidőm év végén, ennyit megér a dolog, mert nekem jobban tetszene a single datastore, ezzel az ssd cache-es megoldással. Ha meg vacak, akkor nem fogom ajánlgatni az eredeti postban körülírt gépbe se, megy minden SSD-re, ami muszáj és kész.
Alapvetően mint kihívás, technológia, stb. érdekel a dolog mostmár :)
ZFS esetén SLOG használatától nem lesz több IOPS-ed érdemben. Annyit gyorsít, hogy szinkron írásnál az SLOG tárolja a ZIL-be szánt adatot, és így a rendszer azonnal vissza tudja jelezni, hogy kész az írás (kikerült nem felejtő adathordozóra), utána pedig a maga rendezkedése után a legoptimálisabban kiírja a tényleges pool-on lévő ZIL-be az egészet, és onnan kerül a majd valamikor a végleges helyére. Szóval egy rossz SLOG még igazából lassítani is tud a többszörös írás miatt, minthogy gyorsítani. Olyan esetben gondolkodnék SLOG-on, ha kellene egy nagy pool ami drága lenne SSD-ből, és az egészet NFS-en ajánlom ki mondjuk VM-ek alá, és az összes írásom szinkron. Na ilyenkor egy jól méretezett SLOG, enterprise PLP-s NVMe meghajtókból tud segíteni az írási IOPS-en a lecsökennő késleltetés miatt. De lokálisan használva a pool-t nagyon kicsi az a felhasználási terület, ahol akár csak mérhető előnyt ad egy SLOG VDEV.
L2ARC-nak (olvasásra gyorsítás) semmi értelme, olcsóbb a több RAM ARC-nak, mint egy jó SSD ilyen célra.
Jelen esetben a tömböt úgy tudnád gyorsítani, hogy a RAID6+0 felállásról RAID1+0 felállásra átalakítanád. Ha mondjuk 2x4 meghajtós tömböd van most, akkor lenne 4x2 meghajtós, azzal dupla annyi IOPS-ed lenne, mint most van. Persze e mellé már kellene egy hot spare, mert 2 helyett csak 1 diszk redundanciád marad az összes redundáns VDEV-en.
Én így csinálom, RAID1+0 HDD pool-t használok VM hoszton és külön RAID1 vagy RAID1+0 SSD pool a sebességet igénylő VM diszkek alá. Az SSD-k mindenképp PLP-s és mix-use típusúak legyenek, mert azonak van normális írási IOPS-ük, amit tartani is tudnak. Pl. Kingston DC600M vagy Samsung PM883-893 az olcsóbbak közül. NVMe SSD-ben M.2 foglalattal baromi nehéz jó diszket találni ilyen célra (főleg a PLP nehéz, a nagy teherbírás már elérhető), NVMe vonalon inkább U.2 és U.3 vagy az új Ex.y csatlakozásokkal találsz megfelelőt.
Minek ? Leirás alapján SSD és kész vagy.
Every single person is a fool, insane, a failure, or a bad person to at least ten people.