CEPH hardver ajánlás

 ( csardij | 2019. május 3., péntek - 16:25 )

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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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.

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.