Helló,
Egy helyen (nyugaton) CEPH kluszter lesz kialakitva (kubernetes cluster alá), kérés, hogy Supermicro szerverek legyenek mert azt tud bérelni/venni.
Ami a turpisság és ebben nem sok tapasztalatom van, hogy jó lenne valami flash (NVME) - alacsony latency miatt - rész is amit adatbázis alá lehet rakni.
A mon és sima OSD-k nem nagy talány, az alábbiakat néztem ki a supermicro kinalatabol:
Mon:
3x 1028U-E1CRTP+
- 2x 250GB SSD OS
- 64GB RAM
- 2x E5-2630 v4 CPU
SATA/SAS OSD:
5x 1028U-E1CRTP+
- 2x 250GB SSD OS
- 128GB RAM
- 2x E5-2630 v4 CPU
- AOC-S3008L-L8e HBA
- 8x 1/2 TB 2.5" SAS HDD (vagy sima SSD, meg kell néznem az árakat még)
- 1.6 TB PCI NVMe
És akkor az nvme node:
NVMe OSD:
2x 1028U-TN10RT+
- 2x 250GB SSD OS (RAID1)
- 256GB RAM
- 2x E5-2690 v4 CPU
- 8x 2.5" NVMe
- Dual port 40GBs QSFP+ NIC
Hálózatban pedig (itt nem kell konkrét hw, cask az igény) ennek megfelelőn:
2x data switch
- 48x SFP+ TGE
- 4-6x 40 GBE QSFP+ (2 az nvme node-oknk, 2 port összekötni egymást, és akkor még marad kettő máshova)
1x management switch (ipmi, management network, stb.)
- 24/48 portos GBE
Terv szerint lenne a sas/sata pool az 5 hdd-sből, 3x replikációval és egy flash pool a 2 node-ból 2x-es replikációval.
Vélemények, javaslatok?
Hozzászólások
SYS-6029U szeretjuk
2U-s gép, azért gondoltam 1U-ban, mert a hely kihasználás végett, valamint később (ha olcsobb lesz) jó lenne SSD-t berakni a sima HDD helyett, akkor meg felesleges lenne 3.5".
akkor meg SYS6019, de en 2U-ba tennem.... jobban szellozik stb.
SSG-6029P-E1CR24L meg a baratod lehet.
En total kezdo vagyok CEPH teren, szoval bocs, ha hulyeseget kerdezek, de miert kell 64GB RAM egy monitor node-ba?
A Mimic doksija azt irja, hogy egy monitor daemon-nak kis cluster eseten 1-2, nagy cluster eseten 5-10GB kell.
A doksi kicsit zavarba ejt, mert daemon-t emleget, ami azt sugallja, hogy egy gepen akar tobb is futhat, de nem hiszem, hogy ez lenne a helyzet.
+1 a kérdésre
Szerintem azért 64 GB, mert mást is rá fog még rakni valamilyen okból, de csak tipp.
@csardij kérlek ha belefér, küldj majd performance teszteket, hogy fog muzsikálni a kész cluster ami majd elkészül.
Ha lenne időd szívesen megnézném, ha lebutítod a hálózati sebességet 1 vagy 10 GB-ra, és hogy úgy mennyit lassul a (dual) 40GBE-hez képest a gyakorlatban.
Én is kezdő vagyok CEPH terén (is), 3 node-os Proxmox + CEPH cluster-t építettem régebben, dual 1 GB-es hálózat esetén egyik porton volt a CEPH összekötve külön switch-en, a másikon pedig a többi gép felé. Ott egyben mindegyik gép monitor is volt egyben, igaz, külön disk-et kapott + az OSD-nek is külön disk-e volt az OS-en kívül. HDD alapokon, hát nem hasított, de működött, viszont 2 gép frissítése közben összeomlott aztán a cluster és újra kellett építeni, mert nem tudta szinkronba csapni magát már a Proxmox. Tesztnek tanulságos volt.
Sakk-matt,
KaTT :)
Gigabit szerintem alkalmatlan ceph ala, egyszeruen a latency mar tul magas, akar meg par cm kiszolgalasahoz is.
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"
Legalább négy ram modul per cpu a quad channel miatt, 4*2*8gb meg kiadja a 64-et.
És a 2 CPU minek? Mon-nak azért nincsenek nagy igényei. A userek meg úgyis az OSD-kel lesznek közvetlen kapcsolatban.
MDS-nek kell a cpu.
CephFS-hez kell? Az vajon jó? Még nem próbáltam.
jónak jó, hogy tartósan milyen, az majd elválik.
nice :)
Elsőre elgondolkodtam, hogy 8 NVMe mellett vajon a vas nem e jelent valahol nagyobb sávszélességet... de elvben jó lehet - 4/CPU, ha jól értem - szóval én is kíváncsi lennék tesztekre, hogy ezek így raid0 /raid1 felállásban mit tudnak :)
Eddig csak 1-2 NVMe lemezzel volt dolgom... de érzésre brutál gyorsak voltak :)
Szép napot!
Miután két évet szívtam egy nagyobbacska ceph clusterrel pár megjegyzés:
- a monitor túl van méretezve első ránézésre. Plusz ebből ugye legalább 3 kell.
- ha eszedbe jutott a monitorra CephFShez MDSt tenni: ne tedd. Sőt, ha lehet, az egész CephFS témát került mint mókus az erdőtüzet, ha picit is megszalad a terhelés / fájl szám, tuningolhatsz kézzel vég nélkül.
- OSDbe szintén hova ennyi RAM? Az a dolga hogy adatblokkokat lapátoljon.
- Az nem derül ki a leírásból, hogy akarsz-e az OSDk közötti hálózathoz külön fizikai hálót, de ha újra kell szinkronizálni egy OSDt, akkor megfelelő beállítás hiányában képes felzabálni a sávszélességet aminek izgalmas következményei vannak.
Ha jól emlékszem dolgoztál már ceph-el, de mindenképpen bástyázd körül alaposan monitorozással, főképp a rebalance szükségességével kapcsolatos metrikákra.
Majd’ egy éve volt hogy utoljára dolgoztam vele, de kérdezz ha tudok segíteni.
--
Pásztor János
3 Eve használok ceph-et napi szinten rbd-vel, cephfs is egy éve van, de nem futottam bele semmilyen problémába és mon-on vannak az mds-ek.
3mon, 5 hdd osd a kezdés. Lehet túl van meretezve, de beszerzesileg egyszerűbb venni 8 egyforma gépet mint pár ilyet pár olyat, cold spare gépet tartani is jobb így.
Osd-be meg azért cache miatt kell a ram, cachelni tud ezerrel és a read performanciara Jo hatással van.
Hálóra nem tudom meg hogy, a meglévőt kell használni vagy azt is ajanljak.
Milyen olyan (nem szintetikus teszt) use-case van, ahol az OSD page cachenek van jelentősége?
Én vm-ekkel használom, ott azt gondolnám, hogy ha valamit egyből vissza kell olvasni, az vagy még a guest page cacheből fog jönni, vagy esetleg az rbd cacheből, ha már ezeken nincs becachelve, akkor az OSD-n sem lesz...
(Mondjuk nálam egy 256GB memóriás serveren van 8 OSD, 8-10 TB-s diszkekkel, szóval amúgy is elég kicsi az esélye, hogy egy random read meglesz pagecacheben)
Valamennyi tapasztalatom van, productionben egyelőre még csak Filestore-ral, és ezek jutottak hirtelen eszembe:
1. A HW-ek alapján gondolom Filestore-ban gondolkozol. Miért nem Bluestore, ha most indulsz? (lsd. Filestore + write amplification)
2. HDD mellé szerintem felesleges NVMe journalnak, pláne ekkora, OSD-nként 5-10GB-nél úgysem lesz nagyobb a journalod. (még SSD mellé sem kell feltétlen NVMe journal)
4. Ha sok a random read, akkor felejtsd el a HDD-ket, pláne adatbázis alá.
5. A cluster network külön hálózat legyen, különben szívni fogsz recovery/rebalancing alatt. (+nyilván bond, tehát én 4 NIC alá nem adnám)
6. Jumbo frame nélkül neki se állj! Production load mellett átállni nehéz, de (nekünk) jelentős performancianövekedést jelentett a jumbo frame használata.
7. ceph logolas minimalis legyen, a latencián sokat javít, ha pl. az összes debug log ki van kapcsolva
Bluestore-t használok minden ceph clusteremben, filestoret nem is igazán használtam élesben.
Egyáltalán nem felesleges, javít a response timeon. Ekkora valóban felesleges, csak kissebbet meg nem találtam a forgalmazó árlistájában.
Adatbázis alá az NVMe only rész lenne rakva ahogy írtam.
A többi irrevelans, több clustert üzemeltetek és nem is ilyen tanácsot kértem. NVMe only nodeok nincsenek meg sehol, az a fő fókusz, hogy ott mi legyen.
Az ilyenek: https://www.supermicro.com/products/system/1U/1029/SSG-1029P-NMR36L.cfm ?
Hogy all a project? Sikerult osszerakni? Ha igen, hogy muzsikal?
Most a compute nodeokat szerezzük be, aztán jön ez.
Betennek ide 2 linket, amelyek nem kapcsolodnak kifejezetten a temahoz, de en nagyon hasznosnak/erdekesnek talaltam oket.
https://leahneukirchen.org/blog/archive/2018/01/anatomy-of-a-ceph-meltd…
https://www.youtube.com/watch?v=OopRMUYiY5E
Az utobbi egy eloadas, aminek az informacio tartalma mar kisse elavult, de ettol meg tanulsagos lehet. + van magyar vonatkozasa.
Szerintem itt amit lehetett elk?rtak nem kicsit, nagyon. Ilyen körülmények között egy gluster vagy akármi SDS is szétesett volna.