Kis vállalati ceph cluster építése

Linux-haladó

Üdv! Szeretnék tanácsokat, javaslatokat kérni egy kis céges ceph cluster kialakításához. Szépen pár hónap alatt, apránként akarjuk felépíteni a dolgokat cept, proxmox alapon. Egyenlőre ~50+ vpst futtatunk egy régi ganetis környezetben, drbd vel amit kinőttünk, ez később teljesen vagy részben átkerülne a proxmox cluster alá. Első körben egy 10-15 vps menne élesben, azt követően pedig 30... tapasztalatok, eredmények függvényében. Nagyjából egy hónapja ültem neki a témának és foglalkozom vele. Jelenleg az alábbi felállásban képzelem el az indulást. Sok helyen írnák, hogy nagyon combos hálózati forgalomra is kell majd számítani, egy 10gbit-es hálózat fejlesztés csak a későbbiekben lesz alternatíva. Jelenleg bonding, lacp, 9000 jumbo frame-el próbáljuk meg.

// 10-15 vps alá
-2x Dell r200: 1x qc proci, 32gb ram, 2x1gbit bonding ceph lan, 1gbit net
-1x Hp dl 160: 2x qc proci, 72gb ram, 2x1gbit bonding ceph lan, 1gbit net
-1x Custrom pc: fx 8320, 32gb, 1gbit ceph lan, 1gbit net, (monitornak később)
-1x Hp dl 180: 2x qc proci, 32gb ram, 4x1gbit bonding ceph lan, 10gbit 2 ceph közé, 1gbit net
-8x2tb hdd data pool
-2x 500gb samsung pro ssd pool, size 2, replica 2
-1x 120gb intel dc s3500 system, monitor
-2x 250gb samsung pro journal 1:4 arányban a hddk mellé
-1x Cisco sg300-20

// 30 vps alá
-4x Dell r200: 1x qc proci, 32gb ram, 10gbit ceph lan, 1gbit net
-2x Hp dl 160: 2x qc proci, 72gb ram, 10gbit ceph lan, 1gbit net
-1x Custrom pc: fx 8320, 32gb, 1gbit ceph lan, 1gbit net, (monitornak)
-2x Hp dl 180: 2x qc proci, 32gb ram, 10gbit ceph lan, 1gbit net
-6x2tb hdd data pool, size 2, replica 2
-2x 500gb samsung pro ssd pool, size 2, replica 2
-1x 120gb intel dc s3500 system, monitor
-2x 250gb samsung pro journal 1:4 arányban a hddk mellé
-1x ZYXEL XS1920-12 ???

Amikor egy journal ssd tönkremegy, az elméletileg az olvasottak alapján viszi magával a 4 osdt is, amit újra kell építeni. Ilyen esetben a hozzá tartozó össes adat használhatatlanná válik a hddken? Vagy az osdk tartalma megmarad, nem kell másik diszkről újra szinkronizálni, elég a hddkből ujjá építeni a journalt?
Mit ajánlanátok megfizethető 10gbit-es swich kategóriában? (Nem az 1M körül gondolkodunk, olyan 300k ig.)
Hp dl 180 at még nem szereztük be, átfutott rajtam a gondolat, hogy dl160 is alkalmas lehet storagenek. Csak 3x2tb hdd pool; 120gb system, monitor; 250gb journal 1:3 arányban; 500gb ssd pool. Igaz egy kis barkácsolás kell hozzá, de nem lehetetlen, ebből 3-5 darab, a több cpu véget jobban megérheti.
Cachet érdemes megfontolni?
Nagyjából ilyesmi felállásban lehet normális teljesítményt kihúzni belőle?

Köszönöm a válaszokat.

  • 6591 megtekintés

( Zsugabubus | 2016. 11. 16., sze – 15:45 )

Szia!

Mivel a journal a frissebb, azt nem lehet a HDD-kből újraépíteni. De annyira nem aggódnék én emiatt, persze valami normális SSD kell. Quad core procinál a 4 HDD OSD-nek jó is, na most olyan SSD kell journalnak, amit a HDD-k max. szekvenciális írási sebességénél gyorsabban lehet írni (aztán jön lassan a BlueStore, amihez már nem is kell journal, vagy legalábbis nagy journal, azt mondják). Több OSD-t nem tennék egy gépbe, mint ahány core van.
Monitorból 1 karcsú, az nem lesz túl HA.
Hálózatban, ha a replikációs forglamat külön tudod választani, azzal már sokat nyerhetsz, elvégre ha 1 írásból 3 lesz a replikálás miatt, arra jó, ha van egy külön interface.

( junior013 | 2016. 11. 16., sze – 16:34 )

Röviden: Felejtsd el!

Bővebben: Mi több mint 1 évig faragtuk, viszonylag combos gépekkel, bond-olt (4x1Gb/node) lan-al, 5 node, 20+ osd. 2 KVM host használta (volna), hasonlóan ~20db VPS-el, de értékelhető teljesítményt nem sikerült kicsikarni belőle :(
~1,5 évnyi kínlódás/szívás után dobtuk az egészet és lett helyette iSCSI. Ugyan a skálázhatóságot és a teljes redundanciát buktuk, de 1db target server a ceph teljesítményének sokszorosát hozza.

Amúgy jól kitalált rendszer a ceph, de legközelebb csak min. 10db node-ból, 10+10Gb-s hálózattal mernék nekiállni - ha van akkora tárhely-/teljesítményigény, amihez így is gazdaságos.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

A kulcs a 10G lesz a node-ok között. Ha 1G elég (volt) a KVM-ek felé, akkor 10G-n vígan elszinkronizál a cluster.
Ahogy lejjebb is írják, a bondolt n*1G az sajnos nem ugyanaz :(

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

+1
tobb hasonlo tortenetet lattam mar, es az 1g egesz egyszeruen latencyben keves sajnos, hiaba bondolsz meg lacp-zel ossze 3-4 1g linket, akkor se lesz soha olyan mint a nativ 10g.
A cephnek pedig kell a 10g, nincs mese :)
Kis olvasnivalo az erdeklodoknek: http://www.mellanox.com/related-docs/whitepapers/WP_Deploying_Ceph_over…

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( freeoli v | 2016. 11. 17., cs – 06:15 )

Inkább ovirt és gluster duoval próbálkozz. A ceph ott jó igazán ahol használják és arra amire használják.

Bocsi, de még idekeverném a hypre-v servert is, ha storage nem free, de ha 15mp replika megfelelő akkor már okes.

Na ez a pfff "Synology" :D

Egy páran szívtak már vele nagyon nagyot. Akkor inkább DRBD + ISCSI meg hasonló kézimunkát javaslok, de inkább azt se.

Ha nem lehet 15 másodperc kiesés katasztrófa esetén akkor komoly bizniszről van szó, tehát komoly pénzből kifér alá pl egy Dell MD vagy vagy bármilyen SAS DAS. Ebben azesetben 2M körül már kaphatsz egy teljesen redundáns tárolót amire 4 hostot köthetsz és kész, megvan a cluster free hyper-v 2016 szerverrel.

Nekunk NFS-en is befosott a Syno, nem kell oda iSCSI. :)
A HA clusteres parban teszteltuk NFS-el es iSCSI-val a problemas dobozokat es mindekettovel elhalt.
Olyan szinten kifagyott mindket node, hogy ki kellett huzni oket es ujrainditani.
Ami azert nem kellemes egy eles rendszeren. A teszteles nyilvan eles uzemet jelentett, mert 2+ hetig nem volt gond a sima uzemben. A hibak randomban jottek elo es meg a Syno support sem tudott mit mondani.

Mi backup-nak hasznaljuk, mert megbizhatatlan.
A 3 x 2 parbol 2 par-nel volt gond. A Syno support odaig jutott a logok elemzesevel, hogy updatelni kell a DSM szoftvert a dobozokon. Ez meg is tortent tobbszor is, majd ra 3 hetre ismet osszeomlott a HA cluster.

Egy kalap fos az egesz, amugy nagyon gyors, de nem megbizthato, mint HA parban.
A legnagyobb gond az volt, hogy nem csak a Syno, hanem mi sem talaltunk semmi ertelmes nyomot, ami miatt a rendszer kiakadhatott volna. Napkozben tortent, amikor nincs mentes, csak sima "normal" forgalom a virtualis gepeken, ami konvergal a majdnem zerohoz. (par mega forgalom van csak)

Syno ds1815 es 815+ volt parban mindkettovel volt gond.
Meg a 1815-rol azt a "jot" lehet felhozni a mentsegere, hogy amikor elszallt, legalabb a masik node tenyleg atvette a szervizeket es eszhez tert.

Viszont a masik 815-os par, csak siman elszallt es mindket node ki volt akadva.
A slave node web interface elerheto volt, ami alapbol tiltott, ha megy a cluster megfeleloen.
A harmadik parnak nem tudom most fejbol a szamat. De az is valami 8xx verzio. Az egyik 1 tapos, a masik 2 tapos. A 2 tapossal volt gondunk.

Szoval 6-bol 4-el volt gond. Eleg rossz arany. :)

A vegeredmeny egy HP MSA1040 lett. Az uj modellben megy barmilyen lemez, nem csak HP.
Plusz ha felhuzod a legujabb firmware-t, akkor megy SSD-vel is. Szoval nagyon cuki kis storage.
Van 1Gb, 8Gb es 10Gb-es modell. Kb 1 milla korul mozog most.
Ja es a HA szerviz valos HA, nem olyan mint a Synology 15 masodperces kiesos buli.
Ezen 4 uplink fut 2 controllerrel, mint az osszes alap HP NAS-on.
Igy a VMware-ben ha kiesik az egyik, akkor max annyit latsz, hogy a path meg van jelolve, mint halott utvonal. Persze ehhez be kell loni a round-robin-t is a szervereken es akkor faszan megy.

Köszönöm a véleményeket. Első sorban nyílt forráskódú megoldásokban gondolkodok. Ovirt-et már én is nézegettem, annak még utána olvasok egy kicsit jobban. Viszont glusterfs volt a ceph előtt mint gondolat, de tesztek alapján az jött le, hogy lassabb mint a ceph, ezért is inkább e felé hajlok első sorban. Valami block eszköz alapú megoldás kellene, redundánsan, használható sebesség mellet, mert ennek stabilan kell működnie, esetleg, ha valami elhullik belőle. Jelenleg 8 node raid1 + drbdn keresztül szinkronizál szépen, viszont már kezdi elérni a határait. Megfordult még a fejemben egy OpenMediaVault nfs HA-ban a iscsi kapcsán, de ha ez elszáll vagy kimarad a net, akkor mindent ránt magával, és újra indul az összes vps a másikról, ami nem egy kellemes dolog.

Ez smallfiles workload (WordPress), szoval ahhoz kellett tuningolni.

Egyreszt a PHP allando stat maniajat megelozendo ugy mountoltam, hogy a gepek elsosoran lokalis cache-bol dolgozzanak (a gluster szol a klienseknek ha valtozott egy file):


"Cmd": [
"glusterfs",
"--no-daemon",
"--log-level=WARNING",
"--attribute-timeout=180",
"--entry-timeout=180",
"--negative-timeout=180",
"--fopen-keep-cache",
"--volfile-server=IP1",
"--volfile-server=IP2",
"--volfile-server=IP3",
"--volfile-server=IP4",
"--volfile-server=IP5",
"--volfile-server=IP6",
"--volfile-id=VOLUME",
"/MOUNT"
],

masreszt meg ezeket allitottam, smallfiles-cli-vel teszteltem (dinamikus filemerettel) es elsosorban a 95 percentile latencyt neztem. Mivel PHP (es persze kepek) ezert igazandibol ez joforman inkabb metadata mint valodi adat, szoval throughput nem annyira volt erdekes.

performance.read-ahead: off
performance.readdir-ahead: off
performance.stat-prefetch: on
features.barrier: disable
diagnostics.client-log-level: ERROR
changelog.fsync-interval: 3
cluster.rebal-throttle: aggressive
cluster.background-self-heal-count: 128
performance.rda-cache-limit: 4GB
config.gfproxyd: disable
performance.client-io-threads: on
nfs.disable: on
transport.address-family: inet
performance.md-cache-timeout: 600
network.ping-timeout: 5
geo-replication.indexing: on
cluster.self-heal-daemon: enable
features.cache-invalidation: on
features.cache-invalidation-timeout: 600
performance.nl-cache: on << ez fontos, not found memory cache
performance.nl-cache-timeout: 600
network.inode-lru-limit: 500000
server.event-threads: 4
performance.cache-invalidation: on
performance.cache-refresh-timeout: 30
storage.owner-gid: 33
geo-replication.ignore-pid-check: on
diagnostics.count-fop-hits: on
performance.cache-size: 8GB
cluster.readdir-optimize: on
performance.io-thread-count: 16
storage.owner-uid: 33
changelog.changelog: on
client.event-threads: 4
diagnostics.latency-measurement: on
cluster.lookup-optimize: on
cluster.favorite-child-policy: majority
server.outstanding-rpc-limit: 256
cluster.use-compound-fops: on
cluster.quorum-type: auto
performance.parallel-readdir: off
features.quota: off
features.inode-quota: off
cluster.enable-shared-storage: enable

Most nem irnam le reszletesen melyik mit csinal ha nem haragszol :)

Ja meg annyi, hogy blk-mq-t es a kyber i/o schedulert hasznalom XFSen

( uid_228 | 2016. 11. 17., cs – 12:40 )

Nem írtad - vagy elsiklottam fölötte -, hogy milyen rendelkezésreállás kell, ill. olyan dolgok is szükségesek-e, hogy live migration. Ha csak virtualizáció és menedzsment egyszerűen, akkor SmartOS + Project FiFo nem opció?

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Jelenleg a dolgok n+1 el futnak drbd mellett, ha egy node leáll, akkor egy másik eszköz átveszi a helyét és onnan indul el újra. Elviekben működik a live migráció a két drbds vps között, de mi non-livet használunk, megvárjuk amíg szépen át transzferálásra kerül miden. Egy rövid kimaradás lehet a szolgáltatásokban, de nem állhatnak le a vpsek a storage kiesése miatt, egy másiknak kell ilyenkor a helyébe lépnie a lehető legrövidebb idő alatt. Utánaolvasok SmartOS + Project FiFo nak is, köszi. Viszont ha megoldható nfs, iscsi a felé is nyitva tartom a kaput.

( akoscomp | 2016. 11. 18., p – 15:17 )

Mi elég korai fázisban letettünk a ceph-ről, mivel elég macerás, és atomstabil és atomgyors hálózati infrastruktúra kell hozzá, ami atomdrága.
Szerintem ott éri meg, ahol nagyon nagy mennyiségű adatot kell redundánsan tárolni, mert cephnél az ideális az, hogy minél több node-on legyen a tárolás, mivel jobban eloszlik a terhelés, csak az ezeket összekötő hálózat kell megfelelő minőségű legyen.
Sajnos teljes redundanciát nyújtó szolgáltatásra nincs ötletem, ami megfelelő minőséget nyújt.
Nekünk belefér egy rövid leállás, ezért a egy zfs+nfs storageon vannak a gépek. Tervezett leállást meg tudjuk oldani storage vmotion-el, vagy máshogy, a storage kihalást pedig bevállaljuk.
Nekünk 5 szerveren 100 vps fut, de még csak 30 került át a zfs+nfs tárolóra.

A mi megoldásunknak nincs konzisztens replikája, tehát ha kihalna a tároló (12 hdd-s supermicro superstorage vas), akkor át kell pakolni a hdd-ket máshova. Ez érzékenyen érintene, de brand storage-on kívül nincs más ötletem, a ceph megfelelően összerakva pedig szerintem drágábban jön ki még a brand storage-nál is.

Ha már zfs van alatta, akkor zfs remote replica. Ha kihal a storage, manuálisan elindítod a másikat. Én legalábbis ezt csinálom 5 perces snapshot-okkal. Ilyen mértékű katasztrófa esetén ennyi adatvesztést bevállalunk. (a különbség annyi, hogy én zvol-okat adok ki iSCSI-n, VM-enként)

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Én is így csinálom, csak egyelőre csak napi replikával, következne, hogy teszteljen pár percessel.
Mik a tapasztalataid? Működőképes, nem jelent jelentős plusz terhelést a szervernek?

Nekem praktikusabbnak és stabilabbnak tűnik nfs-en kiosztani a fájlrendszert a szerverekenk, mivel azt szinte natívan lekezeli a zfs.
Az iSCSI-t hogy oldod meg (os, disztró, iscsi csomag)?

Evvel a megoldással a kiöregedő Dell MD3000i-t váltalánk ki, ami iSCSI-n ment, tehát az sem idegen, de a linuxos iscsi implementációk nem tűntek nekem túl bizalomgerjesztőnek és más os-t nem próbáltam.

Ez jo lehet, de nem jo. A vm-ben talalhato fs es db konnyen inkonzisztens allapotban lehet mentve ha a snapshotot indito process nincs kapcsolatban egy helyi szolgaltatassal ami elegento joggal rendelkezik az os csillapitasara, pl vmware tools.

Erdemes a keszet hasznalni es nyugottan fogsz nyaralni.

A kész rendszerek nagy része sem nyújt konzisztens snapshotot. Nekünk a snapshot mentés mellett fut hagyományos fájlrendszer+db mentés, ami már biztos konzisztens, de ha pl 5 percenként készítek snapshotot, és nem törlöm egyből, akkor szinte biztos, hogy találok egy konzisztenset az utolsó 1 órában.
Másrészt nem kifejezetten bonyolult legalább naponta egyszer api hívással készíteni egy konzisztens vmware (vagy akármi más) snapshotot, és azt is menteni, majd kitörölni.

( kiuka | 2016. 11. 19., szo – 13:11 )

10gbites hálóra én rezest használok. Első sorban költséghatékonyság miatt, manapság már lehet elég sok fajta alaplapot találni 2*10gbase-t csatlakozóval, és a switch (zyxel - 8 portos akkoriban 250e körül volt -) is nagyságrendekkel jobb áron volt, mint az optikai csatlakozókkal szereltek. Bár nem ismerem a HP / Dell szervereket, de biztos találsz közöttük is olyat, amin alapból ilyen csatlakozók vannak, így talán tudod 10G-s hálóval is kezdeni a bonding helyett, ha úgy is az lesz a végcél.

Írták sokan, hogy latency miatt jobb az optika, de alapvetően 0.001-0.0001 msecről beszélgetünk, szóval ez talán a te helyzetedben sem probléma.

Igen, réz 10Gbase-T, optikai meg SFP+

SFP esetén DAC és rendes optikai kábel között is van kölünbség, de nem olyna jelnetős, a dac kb. kétszerese a fibernek.

Itt a különbség nem a fizikai közeg miatt van, hanem az adatok átküldésének módjában, aminél az SFP+ vs. RJ45 interface közti különbségről beszélünk.