- NagyZ blogja
- A hozzászóláshoz be kell jelentkezni
- 4536 megtekintés
Hozzászólások
1PB -ot mivel epited?
250 4TB-os SATA disk, vagy 166 6TB-os lemez árban ugyanott van, ~10MFt.
Es az SSD-k jonnenek a compute node-okba? Leirod, hogy nagyjabol hogyan csinalod?
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
3x-os replikacio miatt 3PB a nyers kapacitas, igy 750x4TB vagy 500x6TB lesz, ezt meg nem tudjuk. minden storage gepbe kell 36 diszk melle meg 2xNVMe SSD journalnak/cachenek.
a compute nodeok teljesen disklessek lesznek valoszinuleg - meg vizsgaljuk, hogy be lehet-e writeback cachenek rakni helyi NVMe diszket ugy, hogy az replikalt legyen halozaton at (KVM alapu az egesz), de kb ugyanazt kell elkepzelni, mint ahogy a pernixdata mukodik (nekik sajnos nincs KVM-es megoldasuk, csak VMware :()
az SSD-k kulon gepekbe mennek, itt az a kerdes, hogy ceph cache pool legyen beloluk, vagy kulon storage tier, vagy mindketto.
ahogy latod, sok meg a nyitott kerdes, ezeket a jovoheten el kell dontenunk, hogy hwt tudjunk valasztani.
- A hozzászóláshoz be kell jelentkezni
es mi lesz a compute node?
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
milyen tekintetben? :-) valoszinuleg fekete az eleje... :D
- A hozzászóláshoz be kell jelentkezni
erdekesen hangzik.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
2xE5-2630v3 + 128GB RAM a kezdo kiepites; aztan lehet 256GB RAM lesz belole, attol fugg, hogy milyen arakat kapunk.
amikor kiszamoltuk a hazat leamortizalva magokra, akkor a 2x2630 lett a nyero, azert ez. de lehet, hogy jobban megerne egy 10 v 12 magos, csak akkor meg a core/gbit nem olyan jo... (2x10Gbit / gep)
- A hozzászóláshoz be kell jelentkezni
Es milyen NIC -ek lesznek bene ? Ill. milyen konfigban ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
a storageokba valoszinuleg 2xChelsio T4 (szoval 4x10Gbit, LACP, frontend-backend kulon), a computeokban Intel 82599ES, szoval 2x10gbit.
Chelsio T5-bol (2x40Gbit) nincs annyink, hogy az osszes storageba az menjen, plusz nem biztos, hogy ki lesz huzva. de ha elfogynaa 2x10gbit, majd bovitjuk.
- A hozzászóláshoz be kell jelentkezni
"a compute nodeok teljesen disklessek lesznek valoszinuleg - meg vizsgaljuk, hogy be lehet-e writeback cachenek rakni helyi NVMe diszket ugy, hogy az replikalt legyen halozaton at (KVM alapu az egesz)"
Ez érdekel, múltkor ilyen megoldást kerestem én is, de nem találtam. :(
- A hozzászóláshoz be kell jelentkezni
commercial biztos nincs, vagy legalabbis en kitarto guglizas eseten sem talaltam. a vmware pedig kizaro tenyezo, a licenszkoltseg elvinne eleg sok penzt ennyi socketre, plusz az OpenStack tamogatasa csapnivalo NSX nelkul, az NSX pedig kulon licenszelodik... :(
read-onlyt nem olyan bonyolult takolni, krdb-vel felhuzod a volumeot, enhanceio/bcache/flashcache/lvmcache/dmcachet rarakod, es a mar cacheld block devicet adod at a KVM VMnek, mint diszk. ha elhal az SSD/gep/akarmi, akkor nincs gond, mivel csak read-only volt.
writeback cachenel ugye mar szivasabb, drbd-vel lehetne szinkronban tartani, csak a management reszt kene lefejleszteni hozza...
- A hozzászóláshoz be kell jelentkezni
A read-only-n gondolkoztom, de én arra jutottam, hogy hiába read-only a cache, akkor is szinkronban kell tartani a két oldalt, mert ha A oldal ír, akkor B oldalon invalidálni kell a cache bejegyzést. Ezt a részét a drbd megoldja, viszont a fölötte lévő cache szoftvernek is "clusterben" kell emiatt futnia. Vagy rosszul gondolok valamit?
- A hozzászóláshoz be kell jelentkezni
egyetlen irasi pont van, az a hypervisor amin a VM fut. a cache write-through, tehat a backing rendszerben mindig a legujabb van (a cache meg invalidalodik az irasnal).
vagy teljesen masrol beszelunk? :)
- A hozzászóláshoz be kell jelentkezni
Altalaban egy cinder volume, egyszerre csak egy nodo-n elerheto, egyszerre max egy instanchoz van attacholva.
Ha nem akarsz shared block devicet, akkor a keplet egyszerubb.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Nekem egy kicsit más volt a felállás. Shared storage volt, és a compute node-okban SSD. Arra húztam clvm+gfs2 kombót. Ebben a felállásban nem tudtam az SSD-t semmilyen módon hasznosítani.
- A hozzászóláshoz be kell jelentkezni
shared storage a compute nodeok alatt (tehat a gfs2-re kerultek a VMek imagei), vagy clvm+gfs2 a VMekben?
mert ha az elobbi, akkor is csak egy iro fel van adott pillanatban (amig nem migralod LV-stul mashova)
- A hozzászóláshoz be kell jelentkezni
Lehet irtam mar, de nekem DRBD-vel vannak rossz tapasztalataim szinkron setupnal, mindenkeppen hajtsatok szenne nyersben a DRBD-t hogy mennyit tud, anno elegge kifekudt a gep + szar volt a sebesseg a replikacio miatt. Remelhetoleg azota optimalizaltak annyit rajta, h jo legyen, de nem tudok jatszani eles hardverekkel, hogy valos mereseket tudjak csinalni sajnos :-(
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
En is keresgeltem, de az igazi kerdes hogy valoban kell -e, ill valoban meg eri -e.
- guest os -ek maguk is cachelnek
- kvm emulal(hat) egy disk cachet
- halozati savszelleseg amugy sem kicsi, es kerdeses mit olcsobb novelni..
- az ssd nek eleg strapabironak es nagynak kell lenie, hogy megerje, ami nem olcso
- ha a ceph maga is rendelkezik ssd cachel, erdemes -e a computnal is kolteni ra ?
ceph-nodokba erdemes lehet ssd -t rakni azert is, hogy egy halala eseten hamarabb legyen uj replika
A tenyleges hasznalatbol, latszik -e hogy van is ertelme, vagy csak cool-nak hangzik ?
Bonusz kerdes, az ephemeral -nak nevezett diskeknel menyire erdekel, hogy safe -e a tarolas (tul el -e egy compute node halalat)..
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
- read cache igen, write cache nem jatszik (rendes appok eseten) OOB
- kvm emulalhat, rbd tud is ilyen caching modot, de ha elpukkan a tap, akkor az ott levo adat kuka (ugyanis a disk cache in-memory)
- a savszel szinte teljesen irrelevans, a latency szamit
- Intel P3700-akat neztuk, az 10DWPD
- a ceph IO pathje _SOKKAL_ hosszabb, mint ha a hypervisor a sajat NVMe eszkozet irna, de ezt erdemes megmerni adott workloaddal*
az ephemeral diszkek SEM pukkanhatnak el, sajnos sokszor nehez a juzernek elmagyarazni, hogy az ephemeral az bizony barmikor elveszhet :(
ha igy lenne, akkor az ephemeralokat valoszinuleg egy full-flash NVMe-s arrayre raknam a ceph melle
*: sajnos - mint minden cloudban - nem nagyon lehet a workloadot becsulni :( amit a juzerek razuditanak, az van...
- A hozzászóláshoz be kell jelentkezni
kvm emulalt cache engedelmeskedik az fsync(2), sync(2) szoval, a tartalom annyira megbizhato, mint egy mezei fizikai disk cache-e.
Ha az alkalmazas/guest nem sync -el rendesen..
Szoval akkor nem akarsz nagyobb write cachet, aminel adodna a kerdes, hogy egyetlen SSD -ben tarolt adat eleg biztos -e.
Edge conditions:
- 10 DWPD nem rosz, de a 400G valtozat ~200 szor ujra irhato naponta (~1GB/sec).
Eleg lehet egytlen user aki 401G filebol `banyaszik` adataokat, sequencialis vegig olvasas in loop.
-- Be tudhato lehet elfogadhato vesztesegnek, ha az ilyen baranyok ritkak.
-- Ha lassitod az I/O -t az ssd kimelesere, akkor tenyleg kell -e ssd cache a compute-n.
- Mire eleg 400G ? Ha 16 instance van a gepen akkor ~24G jutt egy instancra.
Elvileg ez boldoga teheti a userket akik 2G<erdekes_adata_resz<24G kozott dolgoznak,
A kis adattal dolgozok megnyerik a harcot a guest -beli page cache-el. (eleg sok instnace ide szokott tartozni)
A nagyobb 24G adatal dolgozokhoz meg majd szamolod a cache hit rate -et, ill. elgondolkozon azon melyik strategia jo a cache entrik ujra hasznositasahoz.
- Hany disk lehet erintett egy nodon ?
Menyi cache marad, egy diskre, ha mondjuk 128 diskrol kene beszelni ? (Az kozel sem a max)
Hogyan lesz a NVMe fair modon felosztva ?
A felsorolt cachelo modok kozul melyik kepes:
-- egyetlen cachepoolt automatiksuan hasznalni tobb diskhez ?
-- dynamikusan csokenteni, ill. novelni a per disk cache meretet ?
IOPS -ra gyursz, vagy csak latency erdekel ill. csak az abbol adodo IOPS ?
BTW: egyetlen NVMe meg ronthat is throughput ertkeken. (disk write vs. ethernet throughput)
Melyik a fontos ? min, max, avg, 90% ?
Heterogen rendszerben eleg nehez ugy hazudni jo latency -t, hogy ne deruljon ki a
turpissag. Dedicalt cache nodo-ok, sok esetben jobban `hazudnak`.
Ha VM-ek tulnyomo reszenek mem_for_page_cache<erdekes_adat_halmaz<20G akkor valoszinuleg jo megoldas lehet belole,
mas esetben pazarlas es/vagy hatastalan.
'erdekes_adat_halmaz': 90% ban ezt olvassuk.
minden ertek becsult, a tevedes joga fentartva :)
Az elgondolas tetszik, en is filozgattam rajta anno,
de minden virualis disk-hez alkalmazva a sanitycheck -en bizonytalan.
Masodik korben vegig lehet szamolni, nagyobb (esetleg olscsobb) SSD -vel,
ahol arra probalsz meg fogadni, hogy ritkabban kell irni, mivel a read nem ut ki cache bejegyzest.
Aztan..
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
az biztos, hogy olyan cache megoldas kell, ahol egy poolba tudja az ember bedobni a VM diszkeket, nem pedig kulon szeletelni es azt managelni. a juzerek meg nem hiszem, hogy ujrairjak a teljes flasht 10x egy nap, egy hypervisoron...
mivel ugyis publikus (lehet, hogy megerne egy kulon blog postot), igy be tudom linkelni ezt az eloadast az uj generacios szoftveres flash vezerlonkrol, itt is a 10. slideot ajanlanam mindenki figyelmebe: 39x-es steady-state throughput egy full SSD clusteren, TLC SSD-kkel (hello 2TB 850 EVOk)
- A hozzászóláshoz be kell jelentkezni
10 DWPD valoszinuleg eleg a tenyleges irasokra.
Olvasas is eredmenyezhet cache irast, ez ugye megvan.
Tehat arra akarsz fogadni, hogy computot nem fogja tobb,
mint 400GB volum-on tarolt adat erdekelni 2.4h belul ?
Te mennyit sacoltal erdekes adatresznek / per compute node ?
Ha a szam kicsi, nem jobb mondjuk a memoriara bizni ?
Ha a szam nagy lehet, es tenyleg kell a teljesitmeny,
nem jobb mondjuk tobb fajta compute nodot tartani,
koztuk az `I/O centric` fajtat,
ahol megvan trukozes neluk a teljes meret ssd -bol.
- pl. dc s3700, RAID 10 local ephemeral.
IB/iser, hypervisor raid1, is lehetseges,
ha tenyleg problemas diskeket a compute-ba pakolni, es tenyleg kell az
IOPS.
Nem mondom, hogy nincs olyan szituacio amikor local 400G SSD pont jo lene,
a kerdes az, hogy mennyire gyakori.
Ill. van egy viccess work load az idegelenes VM-eknel,
amik erintenek par GB adatot a disken rovid eletuk alatt,
kb. pontosan egyszer, utana page cachebol megy..
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Mi a varhato hatasa egy 36x6TB node elpukanasanak egy 14 node-os clusterben ?
Mennyi ideig, ill. milyen hatasa lesz a teljesitmenyre ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
semmi kb, megfeleloen konfiguralt backfill beallitasokkal. konkret mereseket a kulonbozo dell/hp/supermicro whitepaperekben lehet nezegetni, de egy backfill (ugyan el fog tartani egy darabig) szinte semmilyen hatassal nincs a rendszerre.
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
Erre akkor jól feliratkozom!
--
openSUSE 13.1 x86_64
- A hozzászóláshoz be kell jelentkezni
Sub
- A hozzászóláshoz be kell jelentkezni